torvalds@transmeta.com (Linus Torvalds) wrote on 13.08.00 in <Pine.LNX.4.10.10008131046110.2632-100000@penguin.transmeta.com>:
> Anyway, somebody. Somebody was suggesting the utterly limited and
> braindead interface of "set_extended_attribute(file, xxxx, yyy, zzzz)"
> kind of approach. Which obviously does not handle the generic case.
>
> And I agree with you: I think the only sane _design_ is one that can
> handle the generic case.
>
> "Give them rope", as Joan of Arc used to say.
>
> That was the reason UNIX originally did everything as a "stream of bytes".
> Because in the end, anything else is too limiting.
Here's a radical idea.
Have *both* interfaces.
It's what MacOS does. No, really.
Except MacOS does the attribute-oriented version with a user space
library, and when we have different filesystems using different data
structures on their structured streams, that doesn't work very well.
So we'd have
(1) a way to open("file/stream") or maybe open_stream("file", "stream") or
whatever;
and
(2) a way to get/set_attribute(int fd, void *tag, size_t tagsize, void
*data, size_t datasize) or something similar, for those filesystems which
have a native structure to one or more forks. (You know, you *could*
implement that just as an ioctl. Cue replace ioctl with saner mechanism
thread.)
If you're exceptionally driven, you might even have a way to bind the fs X
structure to the fs Y streams - the only real application for that I know
of is MacOS resource format on NTFS streams, though I suspect OS/2 EAs on
NTFS streams also exists, because NTFS is used as fileserver for Macs and
has an OS/2 1.x compatibility mode.
Cue Al's "do it via mount" idea here as a way of doing that binding.
MfG Kai
-
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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:34 EST