This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Specific Linux syscalls for glibc API
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 18 Nov 2015 17:15:47 +0000
- Subject: Re: Specific Linux syscalls for glibc API
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1511171606330 dot 14808 at digraph dot polyomino dot org dot uk> <564C4DCA dot 3010607 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1511181321270 dot 30047 at digraph dot polyomino dot org dot uk> <564C9B28 dot 6020609 at redhat dot com>
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