Re: A Layered Kernel: Proposal

From: Grigor Gatchev (grigor_at_zadnik.org)
Date: 02/29/04

  • Next message: Dmitry Torokhov: "[PATCH 0/9] New set of input patches"
    Date:	Sun, 29 Feb 2004 16:48:46 +0200 (EET)
    To: Christer Weinigel <christer@weinigel.se>
    
    

    On 29 Feb 2004, Christer Weinigel wrote:

    > Grigor Gatchev <grigor@zadnik.org> writes:
    >
    > > > In the linux kernel I think that one of the most important things I've
    > > > learned from it: middle layers are usually wrong. Instead of hiding a
    > > > device driver behind a middle layer, expose the low level device
    > > > driver, but give it a library of common functions to build upon. That
    > > > way the driver is in control all the time and can use all the neat
    > > > features of the hardware if it wants to, but for all the common tasks
    > > > that have to be done, hand them over to the library.
    > >
    > > By principle, the "least common denominator" type container layers are
    > > bad, because of not being extendable; you are completely right here. A
    > > class-like driver object model seems better to me. And the class-like
    > > model is not the only one that is nicely extendable.
    >
    > > You seem to be knowledgeable on the topic - what driver object model
    > > would you suggest for a driver layer model?
    >
    > Thanks for the confidence, bur I really don't know, it's much easier
    > to criticize someone elses design than to come up with a good one
    > myself. :-)

    Okay. I will try (hope I'll have the time for all!) to outline the major
    driver layer models, with simple lists of advantages and disadvantages,
    and to present it as a base for further discussion. (Please keep in mind
    that this outline will certainly be not the best ever to exist - maybe a
    lot of people around will be able to make it much better. But, anyway,
    they will be given the full opportunity to criticize and improve. :-)

    > With that said, I think that they way the Linux kernel is moving
    > regarding to IDE/SCSI devices is a good idea. Linux has been around
    > for a while now and the Linux people have tried lots of things that
    > turned out not to be such a good idea after all. Many things are
    > still there in the kernel, but if it's important enough, it gets
    > cleaned up after a while.

    If you mean the abandoning of the SCSI emulation, I couldn't agree more.
    Though I haven't digged into the code of this driver group, the move seems
    only logical from design viewpoint.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Dmitry Torokhov: "[PATCH 0/9] New set of input patches"

    Relevant Pages

    • RE: PATCH: Further aacraid work
      ... > This would not be such an issue if Linux provided large SG elements ... > rather than the fubar descending page order ones they issue today. ... Fundamentally, sg lists have to operate at the level of the MMU, so ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: The Well-Factored 386
      ... > And I don't care if you don't like my attitude, ... My job is to keep the lists clean. ... BK and how we shouldn't call linux, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • LinuxPPC developers mailing lists have moved
      ... Linux on PPC developers have moved. ... The current lists are: ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: RFC: i386: kill !4KSTACKS
      ... > we still must keep stack size in mind when coding. ... but Linux is far too complex for that. ... use A, B, C, D" (and I expect these lists to get longer ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)