Alexander Viro writes:
> Folks, I've tried to describe the stuff that may IMO become useful
> for autofs/devfs/portalfs/etc. Comments are more than welcome.
>
> Current problems:
> 5. Any schemes with automount-like stuff in devfs require
> (union-)mount being triggered if lookup brings negative in all
> components already mounted. IOW, if the search gets to the last
> component of union-mount.
I think you're referring here to a "split" devfs, where each driver
exports a mini-devfs. In such an environment, your mount traps would
probably be good.
However, I don't think the mini-devfs idea is a good approach. There
are good reasons for having a unified tree. For one thing, there is
the issue of mounting /. For another, some drivers (i.e. cdrom) need
linkages (not just symlinks) into other parts of the devfs namespace.
Also, it would be hard (or impossible) for related drivers to share
the same directory (i.e. SCSI subsystem). At the least, there would
have to be more co-operation between drivers. Compare this to the
current devfs implementation where things are fairly modular and
independent.
> So what about the following trick: let's allow vfsmounts without
> associated superblock and allow to "mount" them even on the negative
> dentries? Notice that the latter will not break walk_name() - checks for
> dentry being negative are done after we try to follow mounts.
> Notice also that once we mount something atop of such vfsmount it
> becomes completely invisible - it's wedged between two real objects and
> following mounts will walk through it without stopping.
> So the only case when these beasts count is when they are
> "mounted", but nothing is mounted atop of them. But that's precisely the
> class of situations we are interested in. In case of autofs we want
> follow_down() into such animal to trigger mounting, in case of portalfs -
> passing the rest of pathname to daemon, in case of devfs-with-automount
> we want to kick devfsd. So let them have a method that would be called
> upon such follow_down() (i.e. one when we have nothing mounted atop of
> us). And that's it.
> These objects are not filesystems - they rather look like a
> traps set in the unified tree. Notice that they do not waste anon
> device like "one node autofs" would do.
This sounds a lot like the fake inodes I proposed a couple of years
ago to solve the autofs direct mount problem.
Anyway, while these mount traps are a good thing, particularly for
autofs, I don't think they're going to help simplify devfs (without
castrating devfs and probably breaking the Linus-mandated
namespace;-).
Regards,
Richard....
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
