Re: userapi: message versioning

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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 
:kernel.

    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
    structure.

    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.

						-Matt