Hacker News new | ask | show | jobs
by autoliteInline 1729 days 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.
2 comments

There 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_x... [2] http://asm.sourceforge.net/syscall.html [3] https://github.com/torvalds/linux/blob/master/ipc/syscall.c

'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.

Registering 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.
In 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.