> 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