[lkml]   [2012]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Can we move device drivers into user-space?
    On Sun, Feb 26, 2012 at 10:05:59AM -0500, Richard Yao wrote:
    > >> I do not see what prevents an in-kernel context switch into a ring 3
    > >> context with a different process address space. Is it necessary to
    > >> remove the code from the kernel tree before someone can do this?
    > >
    > > No, and that's the real problem here: Everybody who might think it's a
    > > good idea may please implement - and thus propose - something concrete,
    > > try it out and comeback with experience and performance numbers - and
    > > not just try to come up with some theory and other misleading points
    > > (what political aspect?!) and ideas what others should do and why it
    > > might be better.
    > It seems counterproductive to tell people to produce results without
    > doing the brainstorming that such results require.

    It's also counterproductive to tell kernel programmers how they should
    do what they are being paid how to do. If you just want to brainstorm
    possibilities where **you** will do all of the work, as opposed to
    asking the kernel development community to work on your pet theories,
    it's helpful if you more carefully label your poposals as such.

    > If such discussion is not welcome here, then the FreeBSD project has a
    > similar kernel design. Perhaps it would be more productive for those
    > interested in this to brainstorm on their mailing list. If anything
    > materializes, it could be for their kernel instead. Nothing is forcing
    > anyone to do things with Linux.

    My experience is that most researchers produce code which is not of
    production quality. It's very easy to produce a proof of concept that
    works well enough to publish a paper. Making something which is
    actually performant, is **hard**. The problem is that you don't get
    Ph.D.'s for counting cache line misses --- or for getting your
    implementation to the point where cache line misses matter in the
    first place. So the threat that Linux will miss out on some great
    breakthrough is something that is very hard for me to take seriously,
    speaking quite frankly.

    Usenix has awarded best paper awards to work that was done on obsolete
    kernels, where if the goal of that work was to produce production
    kernel code, was in fact horrible work. But if the goal of that work
    is to produce Ph.D. graduates, or to help the professor get tenure,
    was perhaps more successful.

    That being said, maybe you'd be happier engaging with the Minix 3
    community. They are folks who think (unproven, theoretical) safety is
    more important than performance. And they've created a kernel which
    is a 140 times slower at process creation, ten times greater syscall
    overhead, and file copies that were two to ten times slower.[1]


    And Prof. Tannenbaum is an academic, so his goals may be more closely
    aligned to yours.

    Best regards,

    - Ted

     \ /
      Last update: 2012-02-26 21:33    [W:0.044 / U:16.224 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site