> It _is_ in the kernel, it is efficient, it is convenient. It is spelled
> "D I R E C T O R I E S".
Of course directories. Even files ("all is file") :-)
But the kernel must add the next features:
1. Effective storage of small files.
The 'forks' are usualy some 5-10 bytes-long streams per regular file.
It is ugly to store them as regular files or in tarball.
2. Effective opens and locks.
When we open a forked file it is ugly to open all its forks by full
path name and to lock each independently.
Something like h=open(dir);fcntl(h);open(h,fork); - is much faster.
3. Security.
For example the 'ACL' fork can not be supported in userspace without
security holes.
Did I missed something?
P.S. I think, early or later the forks will be in the kernel.
Too many people need it!
The largest problem is *extensibility*.
Some months of discussion about "to do or not to do" is a bit too
long.
The fact that 'forks' can not be simply included in reiserfs and
distributed as modules is a dangerous weakness of our driver system.
Best regards.
Alexander
-
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.tux.org/lkml/