Hans Reiser <reiser@xxxxxxxxxxx> wrote:Oh....;-)
I had not intended to respond to this because I have nothing positive to say, but Andrew said I needed to respond and suggested I should copy Linus.
Yes, but I didn't say "flame Christoph and ignore the issues" ;)
There are lots of little things to do with implementation, coding style,Yes, you are right, but I am not sure Viro will go along with that..... ;-)
module exports, deadlocks, what code goes where, etc. These are all normal
daily kernel business and we should set them aside for now and concentrate
on the bigger issues.
And as I see it, there are two big issues:I don't object to b), though I think b) should wait for 2.7 and reiser4 should not.
a) reiser4 extends the Linux API in ways which POSIX/Unix/etc do not
anticipate and
b) it does this within the context of just a single filesystem.
I see three possible responses:
a) accept the reiser4-only extensions as-is (possibly with post-review
modifications, of course) or
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
c) reject the extensions.
My own order of preference is b) c) a).
The fact that one filesystem willAndrew, we need to compete with WinFS and Dominic Giampaolo's filesystem for Apple, and that means we need to put search engine and database functionality into the filesystem. It takes 11 years of serious research to build a clean storage layer able to handle doing that. Reiser4 has done that, finally. None of the other Linux filesystems have. The next major release of ReiserFS is going to be bursting with semantic enhancements, because the prerequisites for them are in place now. None of the other Linux filesystems have those prerequisites. They won't be able to keep up with the semantic enhancements. This metafiles and file-directories stuff is actually fairly trivial stuff.
offer features which other filesystems do not and cannot offer makes me
queasy for some reason.
b) means that at some time in the future we need to hoist the reiser4what is not comprehensible....?
extensions (at a conceptual level) (and probably with restrictions) up into
the VFS. This will involve much thought, argument and work.
To get us started on this route it would really help me (and, probably,
others) if you could describe what these API extensions are in a very
simple way, without referring to incomprehehsible web pages,
and withoutWell, I agree that there is value in defining things in more detail than we have.
using terms which non-reiser4 people don't understand.
It would be best if each extension was addressed in a separate email
thread.
We also need to discuss what a reiser4 "module" is, what its capabilities
are, and what licensing implications they have.
Then, we can look at each one and say "yup, that makes sense - we want
Linux to do that" and we can also think about how we would implement it at
the VFS level.
If we follow the above route I believe we can make progress in a technical
direction and not get deadlocked on personal/political stuff.
Now, an alternative to all the above is to just merge reiser4 as-is, after
addressing all the lower-level coding issues. And see what happens. That
may be a thing which Linus wishes to do. I'm easy.