[lkml]   [2004]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: silent semantic changes with reiser4
Will Dyson wrote:

> In the original BeOS, they solved the problem by having the filesystem
> driver itself take a text query string and parse it, returning a list
> of inodes that match. The whole business of parsing a query string in
> the kernel (let alone in the filesystem driver) has always seemed ugly
> to me.


> However, the best alternative I've come up with is to simply export
> the index data as a special file (perhaps in sysfs?) and have
> userspace responsible for searching the index.

That is the best implementation suggestion I've heard for splitting the
filesystem into two parts, one in user space and one in kernel, but I
still don't trust it to work well.

> That would probably work, but it wouldn't help other filesystems that
> implement even a different index format, much less a different form of
> extra searchability.
After reiser6 is implemented, we'll have a better idea of what parts
need what from what other parts. Until we get there, it needs to be
kept together. Frankly, I suspect that naming is not going to split so
easily, but when it is done we'll be able to know. The problems of
putting too much functionality into the kernel are less than those of
partitioning the filesystem code, and defining an inflexible API between
the two parts. Kernel interfaces are fairly inflexible because there
will always be some moron who sidesteps the fs library to program
directly to the kernel interface, gets screwed when the interface
changes, has the nerve to complain about it, and works for some powerful

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    [W:0.851 / U:2.992 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site