Implement epoll #102
Implement epoll #102
Conversation
kernel/fs/inode.rs
Outdated
| @@ -216,6 +231,7 @@ pub enum INode { | |||
| FileLike(Arc<dyn FileLike>), | |||
| Directory(Arc<dyn Directory>), | |||
| Symlink(Arc<dyn Symlink>), | |||
| EPoll(Arc<EPoll>), | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
This PR implements epoll system calls for TCP sockets. AFAIK, this implementation covers essential features needed for running Node.js applications.
Closes #19