DragonFly kernel List (threaded) for 2003-07
Re: userapi: message versioning
:Matt: I've been thinking about what you said about versioning, and I
:think that there needs to be a convention that no message size or format
:should be changed without a change to the message: the kernel should
:always accept an older format message or reject it (EINVAL?).
:Whether this is handled by updating the system call number or by having
:a version number field in the message doesn't really matter: a version
:field would make for an easier userland trap for emulating older APIs,
:changing the syscall number would make for a more efficient trap in the
My current thinking is to make the emulation layer responsible for
all version matching.
Here's the idea... all binaries in the system will generally be tagged
with a build version using a non-debug symbol in the binary and/or
tagged in the ELF binary or as a file attribute.
The kernel uses the tag to figure out which emulation layer to load
for the program.
So far so good, the emulation layer matches the program.
For the kernel messaging side of things I propose that all system calls
which transfer complex structures, such as stat*(), getdirentries(),
etc... take and return data as a resource list rather then as a static
For example, stat would return something like: STAT_UID, <uid>,
STAT_GID, <gid>, etc.... (each resource would include the element size).
If we do this then an emulation layer will wind up being both forwards
AND backwards compatible with whatever kernel is loaded in.
We would then only have to specifically create new system calls for
major changes, like changes to the signalling calls.
BUT we have another advantage, and that is the fact that an emulation
layer aware of new calls can back-down to the old ones if the kernel
doesn't recognize the new ones (i.e. you revert to an older kernel). So
a userland program can be built using the new calls and yet still work
reasonably well on a kernel that has the older version of those calls.
In particular I want to avoid the idiocy of creating a userland (e.g.
in FreeBSD-5.0) that is so dependant on new system calls it cannot
run AT ALL on an older kernel or a 4.x kernel. That really pisses me
off. There is no excuse.