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
[email protected]