From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28830 invoked from network); 2 Nov 2020 15:32:44 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 2 Nov 2020 15:32:44 -0000 Received: (qmail 9780 invoked by uid 550); 2 Nov 2020 15:32:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 9759 invoked from network); 2 Nov 2020 15:32:39 -0000 Date: Mon, 2 Nov 2020 10:30:11 -0500 From: Rich Felker To: Chen Wang Cc: musl Message-ID: <20201102153011.GT534@brightrain.aerifal.cx> References: <20201102080416.GB1370092@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Re: [musl] [Question] =?utf-8?Q?somequ?= =?utf-8?Q?estions_about_kernel_header_files_for_musl=EF=BC=9F?= 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