All of lore.kernel.org
 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 13:10:53 +0100	[thread overview]
Message-ID: <87zhh7j38y.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <0B17C6F2-DC2B-4192-B4AD-BD11D6B9F2B6@ubuntu.com> (Christian Brauner's message of "Thu, 07 Nov 2019 13:05:16 +0100")

* Christian Brauner:

> [+Cc Florian, glibc]
>
> On November 7, 2019 12:17:50 PM GMT+01:00, Elichai Turkel <elichai.turkel@gmail.com> wrote:
>>Hi,
>>I'm working on a library that calls syscalls directly to the kernel.
>>`make hedears_install` is a great command to auto generate the UAPI
>>headers that are needed to call the kernel.
>>
>>But the headers are still missing a bunch of defines for flags and
>>structs.
>>
>>I wanted to know if patches to move more things from `./include/linux`
>>to `./include/uapi/linux` are welcome (obviously only
>>typedefs/defines/structs that are required for the syscalls)
>>
>>I think the UAPI is really close to getting a complete set of things
>>needed to communicate with the syscalls, but still not quite there. I
>>would like to push patches whenever I see missing things that my
>>library needs (that way it will be incrementally and by usage only).

The kernel uses some POSIX names with POSIX-incompatible definitions,
e.g. struct msghdr.  Some libcs prioritize POSIX conformance over kernel
conformance and implement userspace translation for mismatch types.
When building against such libcs, it becomes difficult to use UAPI and
libc headers in a single translation unit.  (It is already difficult
today in some cases.)

I don't know a good solution here.  Not using POSIX names in UAPI
headers is one option.  Previously, we have tried to use preprocessor
macros to coordinate definitions, but did not work well in practice
(only few conflicts were ever resolved).  It does not help at all when
the definitions are incompatible.

Thanks,
Florian

  reply	other threads:[~2019-11-07 12:10 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 [this message]
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
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=87zhh7j38y.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.