lkml.org 
[lkml]   [1999]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:2.655 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site