DragonFly BSD
DragonFly kernel List (threaded) for 2003-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: userapi: message versioning

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 21 Jul 2003 11:57:13 -0700 (PDT)

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


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]