On 04/17/16 19:12, Josh Triplett wrote: >> >> 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 -- 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