On 30 Mar 2000, david parsons wrote:
> In article <linux.kernel.Pine.GSO.4.10.10003290615400.20715-100000@weyl.math.psu.edu>,
> Alexander Viro <viro@math.psu.edu> wrote:
>
> > c) the whole concept of monolytic devfs is a bullshit, excusable
> >only because we lack union-mounts. As soon as they are in the devfs will
> >be heading out. There _is_ a point in a driver providing a tiny filesystem
> >with right set of devices and user union-mounting it on /dev,
>
> So you're talking about have every driver known to man build their
> own little devfs and stacking it on top of the /dev heap?
Not. Notice that devfs has a _lot_ of code dealing with load-on-demand and
friends. It's not a code for filesystem - VFS is the right place for that
kind of stuff.
> This strikes me as somewhat naive, for a couple of reasons:
>
> * every unionfs implementation I've ever looked at mentions
> somewhere in their documentation that it's at the very least bad
> for performance to heap on lots of layers
Homework assignment: compare and contrast unionfs and union-mount. Pay
special attention to difference in semantics for subdirectories and
resulting difference in complexity. Consider the cost of layering as
opposed to loop through components in lookup and readdir.
Seriously, if you will look at the stuff JSP did you will see that it's
solving a totally different problem - normal use consists of putting a
layer atop of existing tree and getting COW semantics. It's completely
different set of requirements - for the task in question you need union
only in mountpoint and no COW in sight. That removes 99% of complexity -
you don't need layers, for one thing.
> * you'd want EVERY DRIVER to implement their very own little file
> system so it could automagically union-mount itself onto /dev?
> For some reason, ``code bloat'' is the very first phrase that
> came to my mind.
Certainly I don't. It's not going to be "very own", for one thing. Most of
the code will be in the infrastructure. Moreover, the thing will simply
store the whole tree in dcache - since all instances will share this tree
it's completely OK. Which removes the need in ->lookup() and ->readdir()
- generic code (shared with procfs, devpts, shmfs etc.) will do just fine.
So all you need to do in this 'filesystem' is to call vfs_mkdir() several
times to create your directories and then populate them with devices, also
using the standard functions. Look: instead of having the 'backplane' and
using it as template for dcache tree you can just add stuff into the tree
itself.
-
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 : Fri Mar 31 2000 - 21:00:27 EST