Two filesystem layers are indeed terrible. What you are doing is not
analogous to, say, putting a file system ontop of a disk driver which is
ontop of a piece of hardware, no, you are writing a C interpreter in
Pascal. You are putting a motorcycle seat ontop of a truck chassis, and
then you are asking me to define why a truck chassis isn't as functional
as a motorcycle chassis, and given that you have already built a truck
chassis, you ask why it is that I think you won't have all the
functionality of a motorcycle using your motorcycle seat and handlebars
ontop of a truck chassis. What you want to do is like telling the TCP/IP
guys when they wrote TCP/IP that they should be using the serial line
driver as the bottom layer of their TCP/IP implementation, putting the
TCP/IP stuff in user space, and then preaching about the benefits of
increased portability to other Unixes that would result from that.
Hans
Alexander Viro writes:
>
>
> On Fri, 25 Jun 1999, Albert D. Cahalan wrote:
>
> > Linux is not UNIX(R) at all. Linux is a hot new operating system
> > designed for the next century^H^H^H^H^H^H^H38 years. UNIX(R) is dead.
>
> UNIX(R) is dead, long live UNIX! ;-)
>
> Seriously, Linux definitely *is* one of Unices. And this family will live
> long after the current crop Frankenstein creatures will be dead.
> Linux, BSD, Plan 9, Inferno, etc. are here to stay. MacOS kernel will be
> dead in a couple of years. NT will follow. Monsters do not procreate -
> they only infect each other. Having sex with them is *not* a healthy idea.
> One of the nastiest STDs in that area is called featuritis...
>
> > > Good luck doing that. If you are going to invent a new uniform
> > > scheme - fine, go ahead, implement it as filesystem and I will write a
> > > loopback-mount-on-the-fly. Oh, and don't forget to make them switch to new
> > > format. Deal?
> >
> > That is one way to implement the API, but it won't let the document
> > share allocation and namespace support with the filesystem.
> > You still end up going through two filesystem(-like) layers.
>
> Sheesh... Once more. Slowly. Those crapplications already support
> monolitic formats. Mutually incompatible. They are not, I repeat, *not*
> going to switch to any new scheme. No matter what this scheme will be. For
> them it means massive rewrite. And they will have to support other
> platforms (2.0/2.2 if we are talking about Linux) anyway, so it's *adding*
> new code. Making the kernel understand their current formats means that
> *we* will have to do the same job instead of them. For every vendor. For
> every crappy format. So either you can con/blackmail/persuade those
> vendors to switch to unified format or you are calling for massive pain in
> the ass.
>
> Two filesystem-like layers are not that terrible, BTW. Especially
> with the new page cache - provided that format in question will not be too
> horrible you'll get almost no difference in performance.
>
> The main problem being to make them *use* whatever API you will
> provide. Good luck doing that.
-
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/