lkml.org 
[lkml]   [1999]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: albods are not a clean set of orthogonal primitives (was Re: File systems are semantically impoverished compared to database and keyword systems: it is time to change!)
       From: Hans Reiser <reiser@ceic.com>
    Date: Thu, 24 Jun 1999 15:25:09 +0000 (/etc/localtime)

    Placing the filesystem into user libraries exo-kernel style is another
    orthogonal issue. I don't want to start an exo-kernel implementation
    right now, especially not without doing it completely and systematically
    for all of the filesystem.

    I'm not sure what you mean by "completely and systematically for all of
    the filesystem"; I think a user library approach has the advantage that
    it indeed works for all filesystems (not just one specialized filesystem
    like NTFS 5), and for all operating systems (not just Linux). This is a
    big win!

    I also take issue with your calling what I described in my straw-man
    proposal as an exo-kernel approach. There isn't the user->kernel->user
    mode transition which is typical of standard exo-kernel approaches (and
    which generally incur enough of a performance penalty to be
    problematic).

    What I was demonstrated was a pure user-mode-only approach, just to show
    it was possible. In fact, if people want to play with filters that show
    different views of the file, I would strongly encourage that it be first
    prototyped using a userspace library approach, for the following
    reasons:

    1) Application writers will likely not use this thing unless there is a
    way to get the same functionality across a wide number of Unix
    platforms.

    2) It is easier to test out approaches and semantics in user-mode than
    in kernel mode. Doing it in kernel mode first risks doing a lot of work
    which then either has to be thrown away, or which the kernel programmer
    ends up clinging to because it represents so much investment, in spite
    of the fact that application writers are telling him that this is not
    what they want. Let's get the semantics and the functionality and the
    interfaces right first, before we try thrusting it into the kernel.

    3) The Unix way is to try doing things using a decomposed tool chain or
    user space first, and only then pushing functionality into an integrated
    program or into the kernel if absolutely necessary. If it turns out that
    performance and maintainibility and functionality is perfectly adequate
    using a pure user-mode approach, then perhaps, just maybe, it means it
    doesn't belong in the kernel.

    - Ted


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

    \
     
     \ /
      Last update: 2005-03-22 13:52    [W:4.242 / U:0.492 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site