[lkml]   [2004]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: silent semantic changes with reiser4
On Thursday 26 August 2004 11:03, Anton Altaparmakov wrote:

> Please don't forget that if the reiser4 features are merged as they are
> now, then we will likely be stuck with the API reiser4 chooses. There
> will be tools that will rely on it springing up no doubt.
> Moving the reiser4 features to VFS later is fine and good, but what if
> the VFS doesn't want the same API for those features? Either we would
> have to allow reiser4 to continue providing the old API even though the
> VFS now provides a new, shiny API or we would have to break all existing
> API users on reiser4. Things like "I rebooted into the latest kernel
> and my computer failed to boot because essential app FOO failed to
> access the reiser4 API - Help!" spring to mind.

Andrew Morton wrote:
>b) accept the reiser4-only extensions with a view to turning them into
>   kernel-wide extensions at some time in the future, so all filesystems
>   will offer the extensions (as much as poss) or

If option b) is chosen Reiser4 can become a playground.

There is the reiser4() syscall which you surely don't want to implement for
other filesystems.
Once there is some experience with this new fancy stuff the dust what
is useful/insecure, etc. and what is not will settle and can be condensed
into a vfs api.
Apps like samba and user scripts will have to be adapted once this is
the case, but this should not be to big a problem if this stuff is marked

People which want something stable can continue to use xattrs and a
magnitude of filesystems for now.

lg, Chris

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site