On Tue, 15 Aug 2000, Mo McKinlay wrote:
> YES, an API. Call it magical if you want, but anything else is a
> *HORRIBLE* kludge, and shouldn't be considered, let alone touched with a
> bargepole.
>
> It's VERY simple:
>
> - stat() returns an extra flag if the object being queried has streams.
> - stat() returns an extra flag if the object being queried has EAs.
> - EAs are accessed using a specific API.
> - Whether streams are access via a kludge to open() to modify the
> namespace or an open_stream() call is not something I'm too bothered
> about. If people can come up with a printable character that's not valid
> anywhere else, then fair enough. '/' and ':' are already out of the
> question for reasons previously discussed.
>
> There is no sane way to handle every aspect of this without some sort of
> API.
Wonderful. Now, the question being: is it worth the trouble? And yes, that
applies to _ANYTHING_ that requires new API. Occam's Razor. Ignoring that
had already brought us a shitload of ugliness.
In other words, you'ld better show that the object in question is needed
and that no equivalents can be done in sane way.
So far I've seen only one argument: HFS, HPFS and NTFS support. The rest
of the mentioned reasons does not fit the test above.
I seriously suspect that supporting NTFS can be done within a normal UNIX
API. Yes, "streams" as files. EAs _may_ be different. However, I would
really like to see what software is going to use them on our side of
things. Just to check whether there is a better way to do what that
software really wants.
Consider that as a difference in philosophies if you want. And look at the
UNIX history - every bloody time when we departed from "everything is a
file" we had paid with tons of ugly code, both the kernel and userland
one.
-
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:36 EST