Messages in this thread |  | | | Date | Tue, 1 Sep 1998 23:36:28 -0400 | | From | "Eric S. Raymond" <> | | Subject | Re: 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="http://www.tuxedo.org/~esr">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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
|  |