Re: [PATCH v2 0/2] vfs: Define new syscall getumask.

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