Re: reiser4 plugins

• Previous message: Lincoln Dale: "Re: reiser4 plugins"
• In reply to: Gregory Maxwell: "Re: reiser4 plugins"
• Next in thread: David Masover: "Re: reiser4 plugins"
• Reply: David Masover: "Re: reiser4 plugins"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date:	Sun, 26 Jun 2005 17:16:13 +1000
To: Gregory Maxwell <gmaxwell@gmail.com>

Gregory Maxwell wrote:

>On 6/26/05, Lincoln Dale <ltd@cisco.com> wrote:
>
>
>>the l-k community have asked YOU may times. any lack of response isn't
>>because of the kernel cabal .. its because YOU are refusing to entertain
>>any notion that what Reiser4 has implemented is unpalatable to the
>>kernel community.
>>
>>
>
>A lot of this is based on misconceptions, for example in recent times
>reiser4 is faulted for layering violations.. But it doesn't have them,
>it neither duplicates nor modifies the VFS.
>
>It has also been requested that reiser4 be changed to move some of
>it's operations above the VFS... not only would that not make sense
>for the currently provided functions, but merging was put off
>previously because of changes to the VFS.... now that it doesn't
>change the VFS we are asking hans to push it off until it does??
>
>
<sigh>

it has NEVER been a case of Reiser4 not being merged because "it
required changes to VFS".

the whole point of VFS is to provide a standard API for data to/from
individual filesystems.
over the course of history, VFS itself hasn't been a static thing - it
has had to adapt and change as a result of the needs of filesystems.
but it hasn't ever been a case of individual filesystems doing
'proprietary' things (i.e. there isn't a sys_ext3() system call) - where
it has made sense to do things at a VFS layer, VFS itself has been
adapted to handle those things.

a semi-recent example of this is extended attributes.
it is with some irony that on my desktop i make use of the excellent
open-source desktop search tool 'beagle'.
it, however, uses extended attributes for storing things - and Reiser4's
EAs are incompatible with the "standard" EAs such that Reiser4 is
incompatible with beagle.

this is the WHOLE point of standardization .. i don't think its that
Reiser4's EAs offer any more or less capabilities than standard EAs -
BUT they haven't used the standard mechanisms available for implementing
them, such for Beagle to work on Reiser4, there now needs to be logic
added to Beagle to do so.

lets take this a step further. what about compression? do we accept
that each filesystem can implement its own proprietary compression via
its own API - and now we need individual user-space tools to understand
each of these APIs?
how about encryption?
... and so-on.
suddenly every user app out there needs to have specialized knowledge of
each type of filesystem.

Hans should be applauded for the 'plug-in' concept and showing how it
can be used. however, from an implementation stand-point, it really
shouldn't come as any great surprise that numerous kernel developers are
pushing back saying 'layering violation' and "why can't this be done at
the VFS layer".

none of this is rocket-science. its just plain common sense.

>It's a filesysem for gods sake. Hans and his team have worked hard to
>minimize its impact and they are still willing to accept more
>guidance,
>
i don't see any acceptance at this point. simply lots of hot air that
smells like marketing & PR.

cheers,

lincoln.
-
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/

• Previous message: Lincoln Dale: "Re: reiser4 plugins"
• In reply to: Gregory Maxwell: "Re: reiser4 plugins"
• Next in thread: David Masover: "Re: reiser4 plugins"
• Reply: David Masover: "Re: reiser4 plugins"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]