Re: reiser4 plugins

[Lincoln Dale]

Gregory Maxwell wrote:

> On 6/26/05, Lincoln Dale <ltd@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/