This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Specific Linux syscalls for glibc API


On Wed, 18 Nov 2015, Florian Weimer wrote:

> > (If we drop the libinux-syscalls.so.1 idea and accept Linux-specific 
> > interfaces in libc.so.N, I don't object to erring on the side of treating 
> > more interfaces as Linux-specific in the first instance with generic stubs 
> > potentially being added later.)
> 
> sched_getcpu is already Linux-specific, no?

I see nothing Linux-specific in concept about such a call.  I'm not making 
proposals for which currently Linux-specific interfaces should be part of 
the OS-independent API, but I suspect plenty should be to be at all 
consistent with the practice followed by BSD and SVID interfaces.

> >>> * getrandom, plus BSD getentropy wrapper (bug 17252).
> >>
> >> A high-quality implementation of getrandom is difficult because the most
> >> interesting property of getrandom is that it cannot fail in some modes
> >> of operation.  A wrapper would have to provide reliable emulation,
> > 
> > That's not our problem to solve.
> 
> I disagree.  We have to provide interfaces which are reasonably
> convenient to use.  If we don't do that, programmers will need to write
> their own wrappers, and everyone loses.

It's inevitable with new interfaces that people need to deal with them 
being conditionally supported.  Being easier to use than directly calling 
"syscall" should be enough for adding an interface, for anything useful to 
more than just a very few applications.

A fallback that uses /dev/urandom and /dev/random is probably desirable, 
especially if a getentropy wrapper is provided, but there's no need for it 
to be a cannot-fail fallback.  Applications will already handle failure in 
existing code using /dev/urandom.

> >>> * renameat2 (bug 17662).
> >>
> >> I'm okay with that as long as we do not try to provide emulation (so,
> >> return ENOSYS on an older kernel and EINVAL without file system
> >> support).  This system call is rather Linux-specific, though.
> > 
> > I don't see it as Linux-specific.
> 
> Apparently, it's mostly related to overlayfs, which is why I'm wondering
> if it's all that relevant beyond Linux.

I don't see RENAME_EXCHANGE and RENAME_NOREPLACE as having anything 
specific to a particular filesystem.  RENAME_WHITEOUT came later.

> > My concept of OS-independent APIs is intended to be such that the older 
> > BSD and SVID APIs are not considered OS-specific simply if in fact they 
> > were only natively implemented for particular BSD or SysV systems, but the 
> > concept of the API is meaningful for other OSes and it's plausible at 
> > least some features could be supported on other OSes if someone so 
> > desires.
> 
> And that's actually quite difficult with renameat2, it does leak file
> system implementation details (as does posix_fallocate).

I don't see any file system implementation details in RENAME_EXCHANGE and 
RENAME_NOREPLACE.  If certain file systems do not support such atomic 
operations, then of course the function should give an error when used on 
such a file system.

I think, however, this discussion illustrates a major problem with the 
libinux-syscalls.so.1 idea: if there is no clear technical way to tell 
whether a particular interface belongs in that library, then you can get 
cases of interfaces that appear Linux-specific at first and then are 
adopted by another system and join the OS-independent API later, meaning 
either different systems have them in different libraries or glibc for 
GNU/Linux ends up having copies in both libraries when the interface moves 
to libc.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]