tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Sharing ELF definitions between NetBSD userspace and kernel
On Tue, Nov 25, 2025 at 09:22:48PM +0000, Joseph Koshy wrote:
> - Currently, userland code in NetBSD expects the kernel header
> <sys/exec_elf.h> to implement ELF-related symbols.
>
> However, from the POV of the kernel, almost all of the content of
> this file is clutter -- only a small portion of the content in
> <sys/exec_elf.h> is actually relevant to the kernel.
The correct way to fix this (as well as all the other kernel headers
that are full of bits of libc, which is a lot of them) is as follows:
(1) Choose a different prefix, say "kern".
(2) Move the declarations that need to be shared between user and
kernel to a file in the new prefix, in this case say <kern/elf.h>.
(3) Move the libc/userland-only definitions to a userland header in
src/include; the baseline case is obviously to keep the same name
(thus src/include/sys/exec_elf.h). In this case if we want to make the
breaking change it's reasonable to pick something else like just
<elf.h> and thus src/include/elf.h.
(4) The userland header includes the one from the shared prefix; that
is, it begins with #include <kern/elf.h>.
(5) Leave the kernel-only parts in the existing kernel header and also
include the shared header.
(6) Document, at the top of each header in kern/, how to correctly get
the definitions in it: in this case <sys/exec_elf.h> for the kernel,
and perhaps <elf.h> for userland. Otherwise people will find the
definitions with grep and include them directly and get themselves in
trouble.
(7) Hold the line against making any <kern/*.h> part of any supported
or documented application-facing interface, or use any of these
headers directly from userland code. Failure to do this in the first
place thirty years ago is why <sys/*.h> is full of userland bits.
Note that it's not necessary to have a 1-1 relationship between kern/
headers and sys/ headers; there are bits of shared definitions that
need to be visible from multiple places. Making each group of those
its own kern/ header gives a simple way to organize that logic.
But also, observe that doing this without making a mess requires
renaming src/sys/sys into src/sys/include/sys (so we can also have
src/sys/include/kern) -- this require progress on version control and
that's why this cleanup has been waiting the past FIFTEEN YEARS or
however damn long it's been by now.
--
David A. Holland
dholland%netbsd.org@localhost
Home |
Main Index |
Thread Index |
Old Index