Thread (28 messages) 28 messages, 12 authors, 2016-04-18

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

flat view

From: H. Peter Anvin <hidden>
Date: 2016-04-18 02:16:14
Also in: lkml

On 04/17/16 19:12, Josh Triplett wrote:
quoted
I really like the 'libinux' idea, did anyone every hack up a first-pass
at this?  And I'm guessing we have more syscalls now that would need to
be added (like getrandom(), but that shouldn't be too difficult.
Personally, I'd suggest that libinux should wire up *all* (non-obsolete)
syscalls, not just those that haven't already been exposed via any
particular libc implementation.  Each such syscall function would have
minimal overhead, since unlike libc these wrappers would not have any
special handling (other than use of the vdso) and would directly map to
the kernel syscall signature.  Given a standard prefix like sys_ or
linux_, that would provide a clear distinction between direct-syscall
functions and libc functions, and avoid any future conflict if libc adds
a function named the same as the syscall.

As a random example, sys_getpid() would *always* call the getpid
syscall, rather than reading a cache within the library.  (And
sys_gettid would call the gettid syscall, rather than failing to exist.)
I'm not so sure this is a good idea.  It has definite pros and cons.  In
some ways it pushes it more to be like syscall(3).

	-hpa
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help