[musl] [Question] some questions about kernel header files for musl？

[musl] [Question] some questions about kernel header files for musl？

[Chen Wang]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

hi, I'm a newbie learning msul, I have some questions about kernel header files for musl. Appreciated if anybody can answer my quesitons, thanks in adv.

Q1) What's the rule to pick up kernel header files for musl? Do we need to catch up the latest kernel when the kernel is upgraded? What version of kernel is musl currently in usage?
Q2) I see duplicated headers files in different folders, for example: unistd.h, I see it under both "include/unistd.h" and "src/include/unistd.h". Why we need multiple copies? Are they used for different purpose?
Q3) For different arch, such as arm/x86/riscv, do they share the same kernel header files? I double checked android bionic and found it has different kernel header files for differnet arch.

Best Regards

Wang Chen

[-- Attachment #2: Type: text/html, Size: 1418 bytes --]

Re: [musl] [Question] some questions about kernel header files for musl？

[Szabolcs Nagy]

* Chen Wang <unicorn_wang@outlook.com> [2020-11-02 15:44:38 +0800]:
> hi, I'm a newbie learning msul, I have some questions about kernel header files for musl. Appreciated if anybody can answer my quesitons, thanks in adv.
> 
> Q1) What's the rule to pick up kernel header files for musl? Do we need to catch up the latest kernel when the kernel is upgraded? What version of kernel is musl currently in usage?

musl can be built without linux headers.

you can use whatever linux version to build your toolchain,
but recent ones (e.g. linux v5.*) will have less issues when
libc and linux headers are included together in some code.

> Q2) I see duplicated headers files in different folders, for example: unistd.h, I see it under both "include/unistd.h" and "src/include/unistd.h". Why we need multiple copies? Are they used for different purpose?

src/* is musl internal, it is only used for building musl.

> Q3) For different arch, such as arm/x86/riscv, do they share the same kernel header files? I double checked android bionic and found it has different kernel header files for differnet arch.

musl does not use linux headers. it uses its own
target specific definitions see arch/*/bits/*.h,
an installed header set is only valid for one arch
because the bits/ directory is arch specific.

linux headers are similar: different targets cannot
share the same headers because the asm/ directory
is arch specific.

Re: Re: [musl] [Question] somequestions about kernel header files for musl？

[Chen Wang]

[-- Attachment #1: Type: text/plain, Size: 2116 bytes --]

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?
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? 
Doesn't it look better  to directly use linux uapi header files?





Best Regards

Wang Chen
 
From: Szabolcs Nagy
Date: 2020-11-02 16:04
To: Chen Wang
CC: musl
Subject: Re: [musl] [Question] somequestions about kernel header files for musl？
* Chen Wang <unicorn_wang@outlook.com> [2020-11-02 15:44:38 +0800]:
> hi, I'm a newbie learning msul, I have some questions about kernel header files for musl. Appreciated if anybody can answer my quesitons, thanks in adv.
> 
> Q1) What's the rule to pick up kernel header files for musl? Do we need to catch up the latest kernel when the kernel is upgraded? What version of kernel is musl currently in usage?
 
musl can be built without linux headers.
 
you can use whatever linux version to build your toolchain,
but recent ones (e.g. linux v5.*) will have less issues when
libc and linux headers are included together in some code.
 
> Q2) I see duplicated headers files in different folders, for example: unistd.h, I see it under both "include/unistd.h" and "src/include/unistd.h". Why we need multiple copies? Are they used for different purpose?
 
src/* is musl internal, it is only used for building musl.
 
> Q3) For different arch, such as arm/x86/riscv, do they share the same kernel header files? I double checked android bionic and found it has different kernel header files for differnet arch.
 
musl does not use linux headers. it uses its own
target specific definitions see arch/*/bits/*.h,
an installed header set is only valid for one arch
because the bits/ directory is arch specific.
 
linux headers are similar: different targets cannot
share the same headers because the asm/ directory
is arch specific.

[-- Attachment #2: Type: text/html, Size: 4879 bytes --]

Re: Re: [musl] [Question] somequestions about kernel header files for musl？

[Rich Felker]

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