[lkml]   [1998]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Implementing Meta File information in Linux
Theodore Y. Ts'o <tytso@MIT.EDU>:
> I don't think we need to solve the problem at all. See my previous
> message to linux-kernel about why resource forks really don't buy you
> much. They end up being too transparent to programs like, cp, mv, and
> tar.
> Instead, we're much better off designing a high-level API (implemented
> using a replaceable shared library) for storing and retrieving metadata
> information (and a common metadata format which both KDE and GNOME
> share!!!), and then having a shared library which implements the storage
> of said metadata information via some non-kernel, non-FS means. If
> later somoene wants to extend the filesystem to provide storing resource
> forks, fine we can replace the shared library with one that makes the
> non-standard, non-POSIX API calls, but I really don't see any value in
> storing such information in this fashion over any one of the myriad of
> schemes which don't require filesystem support.

> Do it as in the high-level interface, where it belongs.

Ted's points are well taken. I'll add a few more:

1. If you get the design of something wrong, it's a lot easier to change or
unwire it if it lives in an API library than if it lives in the kernel.
We *will* get the metadata design wrong the first time. Let's do our
prototyping in user space, guys, to hold down the number of potentially
destructive interactions.

2. The right way to think about the Unix file system as it is is that it's
just a namespace manager -- a mechanism that takes pathnames and gives back
byte streams. Resource forks at fs level would be bad design because they
would complicate that abstraction. This is a good reason to avoid doing
them unless there's some overwhelming and obvious gain to be had for the
complexity added -- and I don't see one.

3. This kind of level-mixing mistake has already been made once. System-
V-style file locks should never have been implemented in the kernel;
it would have sufficed to implement them via a shared library with a few
tricks. Instead we got kernel bloat. Let's not make this error again.

(Yes, I've been lurking here for a while. I just never had anything I needed
to say before.)
<a href="">Eric S. Raymond</a>

No one who's seen it in action can say the phrase "government help" without
either laughing or crying.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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