Messages in this thread | | | From | Alexander_Maryanchick% | Date | Tue, 6 Jul 1999 14:22:56 +0400 | Subject | Re: All this resource-fork AKA multiple stream nonsense |
| |
>> You've shown why it must be implement in user space, that's all. It >> could have kernel support by way of _efficiency_ and _convenience_.
> 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/
| |