6 ms·
I don't know a thing about how this works, but if it's a collision problem it sounds like these entry points need the equivalent of a GUID.
by autoliteInline 5y ago
I don't know a thing about how this works, but if it's a collision problem it sounds like these entry points need the equivalent of a GUID.
- deleted 5y ago[deleted]
- blincoln 5y agoThere aren't very many syscalls in Linux - 335 for x86_64[1], 190 for i386[2], etc. I tend to like GUIDs, but AFAIK it would cause a massive backward-compatibility problem to switch to something other than an integer. If I'm reading the kernel source[3] correctly, the syscall interface itself accepts a 32-bit unsigned integer for the call number, but only the lowest 16 bits can be used because the upper 16 bits are used to represent the version. That would still mean that something like 80% of the effective ID space is unused at present. [1] http://blog.rchapman.org/posts/Linux_System_Call_Table_for_x86_64/ http://blog.rchapman.org/posts/Linux_System_Call_Table_for_x... [2] http://asm.sourceforge.net/syscall.html http://asm.sourceforge.net/syscall.html [3] https://github.com/torvalds/linux/blob/master/ipc/syscall.c https://github.com/torvalds/linux/blob/master/ipc/syscall.c
- autoliteInline 5y ago'it would cause a massive backward-compatibility problem to switch to something other than an integer.' lol. of course. Suggestion numero two. A dedicated syscall for additional syscalls that has a dedicated parameter for a GUID. We can add a third level in 2050 or so.
- phendrenad2 5y agoRegistering paths in /dev, /proc, or /sys seems like the way to go. Slightly slower than a syscall, because the kernel has to do text comparison with the path (such as /dev/foobar) you're reading/writing/ioctling.
- oshiar53-0 5y agoIn Linux, the system call number is used as an index into an array of function pointers. Making it a GUID won't really help with table lookup performance -- O(1) random access lookup versus O(log n) binary search.