Linux userland API discussions
 help / color / mirror / Atom feed
From: Christian Brauner <christian.brauner@ubuntu.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Elichai Turkel <elichai.turkel@gmail.com>,
	linux-api@vger.kernel.org, libc-alpha <libc-alpha@sourceware.org>
Subject: Re: Continuing the UAPI split
Date: Thu, 7 Nov 2019 14:36:54 +0100	[thread overview]
Message-ID: <20191107133652.lqp5cqcdtwu22ibd@wittgenstein> (raw)
In-Reply-To: <87zhh7hlbl.fsf@oldenburg2.str.redhat.com>

On Thu, Nov 07, 2019 at 02:23:26PM +0100, Florian Weimer wrote:
> * Elichai Turkel:
> 
> > Thanks for the response,
> > I'm not sure what are you suggesting exactly.
> > A rename to the structs/types so they won't collide with libc?
> 
> Or use namespaces.  I mean, we have had proper technical solutions for
> this issue for more than 20 years now.  I know that this isn't going to
> happen, though.
> 
> > Prioritizing POSIX conformance in the kernel(I think that ship has long sailed)?
> 
> That doesn't really work anyway if userspace has different versions of
> the type depending on feature macros.  Examples are struct stat or soon
> struct timespec on 32-bit architectures.
> 
> > Or just giving up and telling users they can't just directly include
> > both libc headers and kernel headers?
> 
> That's what I've been telling users if they encounter fringe cases I
> can't fix on the glibc side.
> 
> It might also help if top-level types for end user use would be in
> separate headers.  This is what we started doing internally in glibc, to
> disentangle our own headers and eliminate cyclic dependencies.
> 
> > (I'm actually not sure how it works now. because there are definitely
> > collision and if we are using ifdefs and undefs black magic you still
> > end up with a single declaration in the end that might not be
> > compatible with both libc and kernel)
> 
> Officially, it's supposed to work today.  We have one glibc developer
> who says that it's easy to solve, but I disagree strongly.  The fact
> that the problems are not fixed promptly suggests that it's anything but
> simple.
> 
> What I've been doing instead is to include UAPI headers directly from
> glibc headers if it's technically feasible.  (It's not possible in POSIX

A problem I recently ran into that is related are problems with
sys/wait.h and linux/wait.h.
How P_{PID,PGID,PIDFD} used by the waitid() syscall are defined is
different for the two headers.
linux/wait.h uses #define for P_{PID,PGID,PIDFD} whereas sys/wait.h
uses an enum.
The problem is that if I simply don't rely on sys/wait.h and just do
#ifndef P_PID
#define P_PID <value>
#endif
where value is what the syscall expects then technically I need to call
the waitid() syscall directly since it's not at all guaranteed - afaict
- that the P_PID enum == P_PID define that glibc uses for its waitid()
syscall wrapper.
So I'm now in a scenario where I can't call the glibc wrapper for
waitid() with the linux/wait.h defines and I can't call the syscall
directly (e.g. because I want to make use of the syscall's rusage
argument that glibc doesn't expose) with sys/wait.h's P_PID enum.
I'm not sure what the right solution is here...

Christian

  reply	other threads:[~2019-11-07 13:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CALN7hCK0EXLXjPRPr+tuuF2-uQvkLMCFDNzGhv9HS-jrAz6Hmg@mail.gmail.com>
2019-11-07 12:05 ` Continuing the UAPI split Christian Brauner
2019-11-07 12:10   ` Florian Weimer
2019-11-07 13:03     ` Elichai Turkel
2019-11-07 13:23       ` Florian Weimer
2019-11-07 13:36         ` Christian Brauner [this message]
2019-11-07 13:47           ` Florian Weimer
2019-11-07 14:05             ` Christian Brauner
2019-11-07 18:02         ` Carlos O'Donell
2019-11-07 16:21       ` Szabolcs Nagy
2019-11-07 18:05         ` Carlos O'Donell
2019-11-07 20:32           ` Florian Weimer
2019-11-07 22:32             ` Carlos O'Donell
2019-11-08  7:28               ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191107133652.lqp5cqcdtwu22ibd@wittgenstein \
    --to=christian.brauner@ubuntu.com \
    --cc=elichai.turkel@gmail.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-api@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox