I'm confused by that one, it's either I don't understand something and need to learn from Linux queue or there's some flaw in thinking. This makes an Epoll object an element on the filesystem - epoll_ctl(2) used file descriptors, but they're not inodes, they're open files, like sockets.

I guessed that an epoll instance only supports its own special interfaces like epoll_ctl(2), however, it seems an epoll instance also support some FileLike methods. I'll remove Epoll from INode. Thanks for shedding light on this :)

What struck me was the fact in my mental model inode links an element on storage, so traditionally file, directory, character and block devices, UNIX socket and FIFO. Things are getting more complicated on /proc and /sys filesystems, but that's mapping I believe.

Then file descriptors can deal with much more, starting from BSD sockets. And yes, they all have a lot file like methods for opened file (write and read for starter). They usually share use of fcntl() call.

In Kerla, INode points to a singleton of an kernel object can be accessed from file-related system calls such as read(2). It may have a storage or can be a virtual file-like object (e.g. /dev/urandom). A file descriptor, represented as OpenedFile, is a reference to an inode with some states. Most notable states are file position (controlled by lseek(2)) and the CLOEXEC flag.

In that case it's worth renaming to something less suggestive. Don't have good proposal yet as I'd need to understand the mechanism better. Haven't studied that part yet.

Are you suggesting renaming INode? I think we don't need to do that because it's identical to the Linux's concept (inode vs. file).

OK, so it's about all items represented by a form of a filename. Pretty good abstraction. Question is Linux does that for epoll as well? I can check the source later.

I guess so.

OK, so inode_operations is used in all filesystems implementations and refer to objects persistent on a filesystem and sockets (sockfs), shared memory, mqueue. I didn't find the link between inode and epoll.

INode in Kerla represents everything that can be referenced from a file descriptor, no matter whether they can be persisted on a disk.

By the way, I don't want to be too careful about the Linux's internal implementation. What we have to be ensure is its ABI compatibility. Even if the internal implementation is totally different from Linux, if it works well for existing Linux applications, it's OK. Of course it might cause a nitpicky bug. But if it occurs, let's rewrite then in our style.