lkml.org 
[lkml]   [2004]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: silent semantic changes with reiser4


    On Thu, 26 Aug 2004, Jan Harkes wrote:
    >
    > (btw. the same could be implemented completely in userspace, for
    > instance in glibc. Whenever an open call gets an EISDIR error, simply
    > retry the open, but this time with /_contents appended).

    Yes, and no - just to make it obvious before people jump on this, a lot of
    things can be prototyped in user space with things like this, but once you
    have to deal with races and mixed tool environments, user space suddenly
    doesn't work so well any more.

    I think Jan understands this distinction, I just wanted to make sure
    everybody else is aware of the _one_ thing that kernel land does well:

    - safely synchronize globally visible data structures

    That's quite fundamental. 99% of what a kernel does is exactly that. TCP
    would be in user space too, if it wasn't for _exactly_ this issue. A lot
    of people think that kernels are about hardware access, and yes, that's
    the other 99% of the picture (I see the _big_ picture, remember?), but the
    "safe access to common data" is really very fundamental.

    The kernel is literally the thing that makes sure that you don't have -
    and _cannot_ have - user programs that confuse each other by modifying
    data unsynchronized.

    For example, a filesystem is really nothing but a way to access a disk in
    a controlled manner - it's not so much about hardware access, as it is
    about maintaining a coherent view of how some shared data (disk or
    whatever) is maintained.

    Same goes for caches. We could cache things in user space, but if you want
    to _share_ your caches (so that you don't have to re-load them for every
    new application), you need some entity that manages those shared data
    structures in a secure manner. In other words, you need the kernel.

    The same goes for something like a "container file". Whether you see it as
    "dir-as-file" or "file-as-dir" (and I agree with Jan that the two are
    totally equivalent), the point of having the capability in the kernel is
    not that the operations cannot be done in user space - the point is that
    they cannot be done in user space _safely_. The kernel is kind of the
    thing that guarantees that everybody follows the rules.

    Imagine the security problems if a set-uid program were to (unwittingly)
    depend on a user-space library that implements what Jan's prototype
    library would do? Races galore, since a user-space implementation wouldn't
    have _any_ way to do tests like the above atomically.

    Linus
    -
    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/

    \
     
     \ /
      Last update: 2009-11-18 23:46    [W:0.040 / U:0.100 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site