On 04/17/16 19:37, Josh Triplett wrote: > > It seems like one of the main problems with syscall() is that it forces > userspace to handle weird ABI issues, such as syscall numbers varying by > architecture, encoding of 64-bit arguments on 32-bit platforms (see the > example in the syscall manpage), and other subtleties that will break on > architectures other than the one the developer is most likely to be > running. libinux bindings would eliminate those issues. > > What cases do you have in mind where the libinux binding should look > different than the C API of the SYSCALL_DEFINE'd function in the kernel? > > Users can still call the libc syscall when they want libc's behavior; > for syscalls that have a libc binding, most users will want that > version. But I've often needed to call the underlying syscall even for > syscalls that *do* have a libc binding, for various purposes, and having > a standard way to do that while still having safe type signatures seems > helpful. > > This would also make it much easier to write an alternative libc, or a > language standard library that doesn't want to depend on libc. > The main problem has to do with types, and the fact that the C library may want to intersperse itself around system calls. If people start writing programs that call, say, __linux_umask() then it would make it hard for libc to do something special with umask(). There are other things like it, e.g. where dev_t and __kernel_dev_t are concerned. Now, we could of course have __linux_getrandom() and make a weak alias for getrandom(), but I really don't understand the use case for exporting all the system calls. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
