mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Chen Wang <unicorn_wang@outlook.com>
Cc: musl <musl@lists.openwall.com>
Subject: Re: Re: [musl] [Question] somequestions about kernel header files for musl?
Date: Mon, 2 Nov 2020 10:30:11 -0500	[thread overview]
Message-ID: <20201102153011.GT534@brightrain.aerifal.cx> (raw)
In-Reply-To: <OSYP286MB0181DC81E858E28B92164442FE100@OSYP286MB0181.JPNP286.PROD.OUTLOOK.COM>

On Mon, Nov 02, 2020 at 09:28:58PM +0800, Chen Wang wrote:
> Thank you, Szabolcs.
> 
> But as I understand, libc has dependency on os's api, and musl is
> designed target for linux, right? Why musl provide a set of header
> files without directly use user header files from linux?

The kernel headers are not safe to include from libc ones. They're not
namespace-safe, for example -- in other words they may and often do
use identifiers that are not reserved for the implementation. Also
they may define certain types that are suitable for the linkage
between userspace and kernel but not between the application and
standard library, for instance because the version of the type used in
the user-kernel linkage is not POSIX-conforming. For example struct
msghdr and cmsghdr have certain fields as long rather than int in the
kernel versions, and all the sysvipc types lack space for 64-bit
time_t on 32-bit archs.

Further, even if the kernel headers/types were all usable, using them
would require that users have present at build and run time the latest
version of the kernel headers. For example, a version of the syscall
list lacking the time64 syscalls would cause 32-bit musl 1.2.0+ to be
completely miscompiled. Note in particular that musl does *not* want
to know the set of syscalls, network features, etc. present on the
kernel you vaguely intend to be using at runtime, but rather the
*full* API/ABI it can potentially use on a new enough kernel (and it
handles presence or absence of that at runtime).

> I also wonder by current solution for musl, how to keep alignment
> with kernel, I mean if linux changes some in uapi, would musl have
> to make the corresponding changes to catch up with it?

It can't be changed because it's part of ABI. New types/interfaces can
be added but existing ones can't change.

Rich

      reply	other threads:[~2020-11-02 15:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-02  7:44 [musl] [Question] some questions " Chen Wang
2020-11-02  8:04 ` Szabolcs Nagy
2020-11-02 13:28   ` Re: [musl] [Question] somequestions " Chen Wang
2020-11-02 15:30     ` Rich Felker [this message]

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=20201102153011.GT534@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    --cc=unicorn_wang@outlook.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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