4 ms·
1. You missed a thin red line in the diagram. The diagram is not meant to claim that SDL uses libevdev. 2. Sockets are files. No, they don't have filenames usu
by burfog 8y ago
1. You missed a thin red line in the diagram. The diagram is not meant to claim that SDL uses libevdev.
2. Sockets are files. No, they don't have filenames usually, but they do have file descriptors and even inode numbers.
3. The diagram does not imply that the I/O scheduler is a file. The I/O scheduler is listed as a component underlying the listed filesystems.
There are no inaccuracies. That said, the diagram is awful. It is hard to follow (your misinterpretation being a great example) and seems to be a cluttered and incomplete collection of parts.
- hueving 8y ago>2. Sockets are files. No, they don't have filenames usually, but they do have file descriptors and even inode numbers. I challenge you to create a symbolic link to one. :)
- burfog 8y agoln -s /proc/`pidof Xorg`/fd/1 here-you-go Really though, it's the file descriptor that matters. This is the abstraction that lets you do things like pass a socket between different processes in the same way that you'd pass an opened directory between different processes. The few places where this abstraction is missing are painful. A good example is ptrace. You can't pass a ptrace between processes. Handling it nicely in poll or select isn't easy. The use of file descriptors might not seem so amazing today, now that Windows has the HANDLE and MacOS X has the Mach port, but it was revolutionary when it was introduced. For about 15 years, it was just a UNIX thing. MS-DOS had separate ways to deal with everything: files, directories, each different vendor's network stack, etc. Every other OS was like that, more or less.
- hueving 8y agoAh, my memory fails me of the limitation I was running into. IIRC it was passing socket FDs from a process in an ip namespace to a parent process outside of the namespace via a unix domain socket.
- Jasper_ 8y ago> 1. You missed a thin red line in the diagram. The diagram is not meant to claim that SDL uses libevdev. There's an arrow pointing to "SDL input". In theory, it makes sense that libevdev is like libDRM and libasound in being "the officially sanctioned userspace library", but that's not the case -- evdev is much, much older than libevdev and does a lot more than wrap the ioctls. > 2. Sockets are files. No, they don't have filenames usually, but they do have file descriptors and even inode numbers. Lots of things have file descriptors and are not files. For instance, eventfd(). Or timerfd(). File descriptors should probably be renamed "kernel object handles". As for inodes, abstract UNIX sockets do not have them. Seriously, have a program make abstract sockets (sun_path should start with '\x00'), then call lsof. The 'inode' field will be 00000000.
- burfog 8y agoThere is not an arrow pointing to "SDL input". Look again. :-) Spoiler: There is an arrow pointing to a large red box that happens to contain libevdev right below the arrow. To see the edge of the box, you may need to scroll right if your browser has a narrow window. It is a terrible diagram, but it is correct. In UNIX terminology, anything with a file descriptor is a file. Plan 9 would have a filename, but that is a different OS. See the man page for stat(1) where you will find S_IFSOCK. The st_mode value is 0140000 for a socket, which is 0xc000 in hex. I just hacked up the program shown by "man 3 getaddrinfo" to call fstat on the file descriptor and show the results. I get this: fd 3 has inode 325043100, mode 140777 0xc1ff, dev 8 rdev 0 That inode number is the one that shows as symlink content in the /proc/*/fd/ directory listing. Clearly, it works. Sockets do have file descriptors and inode numbers. Inside the kernel, there is even a "struct inode" for each socket.