lkml.org 
[lkml]   [2004]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: silent semantic changes with reiser4
    Date
    From
    David Masover <ninja@slaphack.com> said:
    > Horst von Brand wrote:
    > | Spam <spam@tnonline.net> said:
    > |
    > | [...]
    > |
    > |
    > |> The problem with the userspace library is standardization. What
    > |> would be needed is a userspace library that has a extensible plugin
    > |> interface that is standardized. Otherwise we would need lots of
    > |> different libraries, and I seriously doubt that 1) this will happen
    > |> and 2) we get all Linux programs to be patched to use it.
    > |
    > |
    > | What is the difference with a kernel implementation? Not by being
    > | in-kernel will it make all the incompatible ways of doing this
    > | magically vanish, and give outstanding performance. Plus handling
    > | and maintaining the in-kernel stuff is _much_ harder than userspace
    > | libraries.

    > First of all, only the interface has to be in the kernel. I haven't
    > heard anyone suggest otherwise.

    Right. But it is _another_ interface in the kernel, plus special userland
    code supporting it.

    > Second, there are quite a few things which I might want to do, which can
    > be done with this interface and without patching programs,

    Such as?

    > but would
    > require massive patches to userspace. There have been numerous examples.

    Haven't seen any that made sense to me, sorry.

    > There are some things which can't be solved without patching.

    Maybe. Question is, is it worth it (kernel modifications + userland
    support, or just userland support, or leave it alone). Sure, it might make
    your particular application easier to write (at a cost for _all_ filesystem
    hackers!), perhaps even a bit faster; but is _your_ particular convenience
    worth the cost for _everybody_?

    > Version
    > control is one such thing.

    bk, cvs, svn, rcs, ... are working just fine here, thank you so much. Used
    to work on SunOS and Solaris, even SCO Unix (I used at least rcs and cvs
    there). No Reiser4 in sight.

    > But then there can be more generic patches
    > - -- as soon as the transaction API is done, you only have to patch apps
    > to use that, and have a version control reiser4 plugin.

    Again, _what_ version control exactly? Will the above packages be able to
    make use of it (remember they all are cross-platform (at least cross-Unix),
    and so quite unlikely to make use of a Reiser4 on Linux whackiness...)?

    > | I'd go the other way around: Get userspace to agree on a common framework,
    > | make it work in userspace; if (extensive, hopefully) experience shows that
    > | a pure userspace solution has issues that can't be solved except by kernel
    > | assistance, so be it.

    > We already have such a framework -- it's called "VFS".

    Right. It offers what applications need to build their own stuff. It is
    minimalistic (well, sort of) and time-proven.
    --
    Dr. Horst H. von Brand User #22616 counter.li.org
    Departamento de Informatica Fono: +56 32 654431
    Universidad Tecnica Federico Santa Maria +56 32 654239
    Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
    -
    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: 2005-03-22 14:05    [W:4.331 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site