linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Christian Brauner <christian.brauner@ubuntu.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, 07 Nov 2019 14:47:54 +0100	[thread overview]
Message-ID: <87v9rvhk6t.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <20191107133652.lqp5cqcdtwu22ibd@wittgenstein> (Christian Brauner's message of "Thu, 7 Nov 2019 14:36:54 +0100")

* Christian Brauner:

> 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.

Right, and this is where POSIX mandates that there is a type idtype_t
which is an enum, an that it has members P_PID etc.

What we could do is:

typedef enum
{
  P_ALL,		/* Wait for any child.  */
#define P_ALL P_ALL
  P_PID,		/* Wait for specified process.  */
#define P_PID P_PID
  P_PGID		/* Wait for members of process group.  */
#define P_PGID P_PGID
} idtype_t;

The other header can then use #ifdef.  You'll see that pattern in some
cases already.

But that will only work if you include glibc headers first.  The generic
approach uses some shared macro for the coordination so that things work
both ways.

The other issue here is that it gets rather iffy from a language point
of view if the kernel wants to add additional constants and glibc has
still the old idtype_t definition.

> 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...

Yes, it's a hard problem.  waitid is particularly annoying because POSIX
and the kernel have such different function prototypes.  We could
perhaps expose the actual waitid system call under a different name, and
use int for the ID type parameter.  But that needs someone to write a
patch.  (My efforts to add syscall wrappers have stalled unfortunately.)

Thanks,
Florian

  reply	other threads:[~2019-11-07 13:47 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
2019-11-07 13:47           ` Florian Weimer [this message]
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=87v9rvhk6t.fsf@oldenburg2.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=elichai.turkel@gmail.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;
as well as URLs for NNTP newsgroup(s).