On Mon, 31 Aug 1998 15:08:34 -0700, Hans Reiser <reiser@idiom.com> said:
> With regards to namei() in general:
> I think that what you are failing to realize is that it is possible to
> change namei() while retaining upward compatibility.
> I have a complete set of semantics designed for namei() which are
> based on what russians would call set-theoretic database theory.
> These semantics give you everything that a keyword system or a
> database can give you but with greater generality and abstraction.
That's fine. I have no objection to that, but that's not really what
the discussion about forks started off as.
The issue was about adding extra streams to a file in a way which does
not change the visible contents of the file as seen by a normal open().
It's not an issue of keeping the "main" contents of the file in a
subfork; it's a question of adding subforks _without_ disturbing the
main contents. That, by definition, changes the semantics of namei():
you no longer get the whole contents of the file back when you do an
open() and read().
That is the crux of my objections. If we add such hidden information,
then all our current tools (NFS, tar, cp, mv etc) fail. NFS in
particular is a killer: by adding functionality to the fs which cannot
be encoded in the standard NFS protocol, we lose the ability to share
these files.
If we want to add tagged information to a file, far better to do it via
a dot directory. Keep the problem in user space where it belongs. Any
extra efficiency that the fs has to offer will still be realised by such
a mechanism.
Only where the kernel *has* to be involved (such as for security issues)
can we justify adding the fork in the kernel. That alone justifies
having fork capability in the kernel. It does not justify adding a
generic fork API to the kernel; far better to have a separate ACL API
and let each filesystem deal with it in the most appropriate manner.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html