[lkml]   [2004]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: A Layered Kernel: Proposal

    Here it is. Get your axe ready! :-)


    Driver Model Types: A Short Description.

    (Note: This is NOT a complete description of a layer,
    according to the kernel layered model I dared to offer. It
    concerns only the hardware drivers in a kernel.)

    Direct binding models:

    In these models, kernel layers that use drivers bind to
    their functions more or less directly. (The degree of
    directness and the specific methods depend much on the
    specific implementation.) This is as opposed to the
    indirect binding models, where driver is expected to provide
    first a description what it can do, and binding is done
    after that, depending on the description provided.

    Chaotic Model

    This is not a specific model, but rather a lack of any model
    that is designed in advance. Self-made OS most often start
    with it, and add a model on a later stage, when more drivers


    The model itself requires no design efforts at all.

    No fixed sets of functions to conform to. Every coder is
    free to implement whatever they like.

    Unlimited upgradeability - a new super-hardware driver is
    not bound by a lower common denominator.

    Gives theoretically the best performance possible, as no
    driver is bound to conform to anything but to the specific
    hadrware abilities.


    Upper layers can rely on nothing with it. As more than one
    driver for similar devices (eg. sound cards) adds, upper
    layers must check the present drivers for every single
    function - which is actually implementing an in-built driver
    model. (Where its place is not, and therefore in a rather
    clumsy way.)


    Good for homebrewn OS alikes, and for specific hardware that
    is not subject to differencies, eg. some mainframe that may
    have only one type of NIC, VDC etc. Otherwise, practically
    unusable - the lack of driver systematics severely limits
    the kernel internal flexibility. Often upgraded with
    functions that identify for each driver what it is capable
    of, or requiring some (typically low) common denominator.

    Common Denominator Model

    With it, hardware drivers are separated in groups - eg. NIC
    drivers, sound drivers, IDE drivers. Within a group, all
    drivers export the same set of functions.

    This set sometimes covers only the minimal set of
    functionalities, shared by all hardware in the group - in
    this case it acts as a smallest common denominator. Other
    possibility is a largest common denominator - to include
    functions for all functionalities possible for the group,
    and if the specific hardware doesn't support them directly,
    to either emulate them, or to signal for an invalid
    function. Intermediate denominator levels are possible,

    The larger the common denominator, and the less emulation
    ("bad function" signal instead), the closer the model goes
    to the chaotic model.


    It requires little model design (esp. the smallest common
    denominator types), and as little driver design as possible.
    (You may create an excellent design, of course, but you are
    not required to.) You can often re-use most of the design
    of the other drivers in the group.

    It practically doesn't require a plan, or coordination. The
    coder just tries either to give the functionality that is
    logical (if this is the first driver in a new group), or
    tries to give the same functionality that the other drivers
    in the group give.

    Coupling the driver to the upper levels that use it is very
    simple and easy. You practically don't need to check what
    driver actually is down there. You know what it can offer,
    no matter the hardware, and don't need to check what the
    denominator level ac ually is, unlike the chaotic model.

    It encapsulates well the hardware groups, and fixes them to
    a certain level of development. This decreases the
    frequency of the knowledge refresh for the programmers, and
    to some extent the need for upper levels rewrite.


    The common denominator denies to the upper level the exact
    access to underlaying hardware functionality, and thus
    decreases the performance. With hardware that is below the
    denominator line, you risk getting a lot of emulation, which
    you potentially could avoid to a large degree on the upper
    level (it is often better informed what exactly is desired).
    With hardware above the denominator line, you may be denied
    access to built-in, hardware-accelerated higher level
    functions, that would increase performance and save you
    doing everything in your code.

    Once the denominator level is fixed, it is hard to move
    without seriously impairing the backwards compatibility.
    The hardware, however, advances, and offers built-in
    upper-level functions and new abilities. Thus, this model
    quickly obsoletes its denominator levels (read:
    performance and usability).

    The larger the common denominator, the more design work the
    model requires. (And the quicker it obsoletes, given the
    need to keep with the front.)


    This model is the opposite of the chaotic model. It is
    canned and predictable, but non-flexible and with generally
    bad performance. Model upgrades are often needed (and done
    more rarely, at the expense of losing efficiency), and often
    carry major rewrites of other code with them.


    These two models are the opposites of the scale. They are
    rarely, if ever, used in clear form. Most often, a driver
    model will combine them to some extent, falling somewhere in
    the middle.

    The simplest combination is defining a (typically low)
    common denominator, and going chaotic above. While it
    theoretically provides both full access to the hardware
    abilities and something granted to base on, the granted is
    little, and the full access is determinable like with the
    chaotic model, in a complex way.

    This combination also has some advantages:

    Where more flexibility and performance is needed, you may go
    closer to the chaotic model. And where more replaceability
    and predictability is needed, you may go closer to the CD
    model. The result will be a driver model that gives more
    assets where they are really needed, and also has more
    negatives, but in an area where they aren't that important.

    If the optimum for a specific element, eg. driver group,
    shifts, you may always make the shift obvious. Then, moving
    the model balance for this element will be more readily
    accepted by all affected by it.

    Another way to combine the models is to break the big
    denominator levels into multiple sublevels, and to provide a
    way to describe the driver's sublevel, turning this model
    into indirect binding type.

    All this group of models, however, has a big drawback:
    really good replaceability is provided only very close to
    the common denominator end of the scale, where flexibiility,
    performance, upgradeability and usability already tend to
    suffer. Skillful tuning may postpone the negatives to a
    degree, but not forever. Attempts to solve this problem are
    made by developing driver models with indirect binding.

    Indirect binding models:

    With this model, drivers are expected to provide first a
    description what they can do, and what they cannot. Then,
    the code that uses the driver binds to it, using the

    Most of these models take the many assets of the chaotic
    model as a base, and try to add the good replaceability and
    function set predictability of the common denominator model.

    Class-like model

    In it, the sets of functions that drivers offer are
    organized in a class-like manner. Every class has a defined
    set of functions. Classes create a hierarchy, like the
    classes of OOP languages. (Drivers do not necessarily have
    to be written in an OO language, or to be accessed only
    from such one.) A class typically implements all functions
    found in its predecessor, and adds more (but, unlike OOP
    classes, rarely reuses predecessor code).

    Classes and their sets of functions are pre-defined, but the
    overall model is extendable without changing what is
    present. When a new type of device appears, or a new device
    offers functionality above the current classes appropriate
    for it, a new class may be defined. The description of the
    class is created, approved and registered (earlier stages
    may be made by a driver writer, later - by a central body),
    and is made available to the concerned.

    Every driver has a mandatory set of functions that report
    the driver class identification. Using them, an upper layer
    can quickly define what functionality is present. After
    this, the upper layer binds to the driver much like in the
    direct binding models.


    If properly implemented, gives practically the same
    performance as the chaotic model. Additional checking is
    performed only once, when the driver is loaded. Class
    defining may be fine-grained enough to allow for practically
    exact covering of the hardware functionality.

    The upgradeability and usability of the specific drivers are
    practically the same as those of the chaotic model. And the
    model global extendability and upgradeability, if properly
    designed, are practically limitless.

    If properly designed, gives nearly the same replaceability
    as the CD model. (The things to check are more, but much
    less than with the chaotic model. What you will find in
    each of them is usually well documented. And the check
    procedure is standard and simple.)


    The model itself requires more design and maintenance work
    than the direct binding models (except the larger CD
    models). (Actually, the amount of maintenance work is the
    same as with any CD model, but the work comes before the
    need for it is felt by everybody.)


    This is probably the best of all driver models I have
    examined more carefully. Unhappily, most implementations I
    have seen are rather clumsy, to say the least.

    Function map model

    This model is actually a largest common denominator model,
    extended with the ability to provide a map of the
    implemented functions. In the simplest case, the map is a
    bitspace, where every bit marks whether its function is
    implemented. In other cases, the map is a space of accesses
    (eg. function pointers).


    In some architectures and platforms, this is a very
    convenient way to describe a function array.

    The model is simple, and therefore easy to use.


    The model has all disadvantages of a LCD model.


    The advantages of the model are relatively little, while the
    disadvantages are big. For this reason, it is used mostly
    as an addition to another model - eg. to the class-like

    Global discussion:

    The models list provided here is rather global, This is
    intentional: while designing, one must clarify one level at
    a time, much like with coding.

    The list also is incomplete. For example, I never had the
    time to look properly for ideas into the OS/2 SOM, and it is
    said to work very well, and provide excellent performance.
    Of interest might be also more details of the QNX driver
    model. Someone with in-depth knowledge of these might be
    able to enhance this list.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:01    [W:0.035 / U:7.564 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site