Alexander Viro writes:
>
>
> On Wed, 3 May 2000, Richard Gooch wrote:
>
> > 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.
>
> And what's up with mounting /?
Well, it depends on how you plan on making the VFS work. Firstly, I
need to be able to add and remove inodes without devfs being mounted
(so / can be mounted). Also, I need to be able to grab hold of an
inode by name.
Next, if the mini-mounts idea is used (a mini FS per driver), they
will all have to be brought together (need a new name for mounting
which isn't really mounting (or is it mounting, just not exposing to
user-space?)). The unified namespace needs to be available to the
kernel: we can't wait for user-space to do that.
> > 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.
>
> Why? union-mount their trees on /dev/scsi and you are done. No?
No, I don't think that will work. The problem is that the high-level
drivers share a directory: the deepest directory. So the directory for
the "device" would be: /dev/scsi/host0/bus0/target0/lun0/
and then the sr_mod driver has to create the "cd" entry and the sg
driver has to create the "generic" entry. This is because the
high-level drivers present different "views" of the same SCSI device.
If we had the original devfs naming scheme of /dev/sr/ and /dev/sg/
and so forth, it would be easy to separate things. But with Linus'
naming scheme, it's not so simple (although I do agree that his scheme
is cleaner (but he had to drag me a bit:-)).
Anyway, tell me how you see this working with union mounting.
Also, please tell me what splitting devfs into a pile of mini-devfs'
buys us? If you're thinking that it will solve the multi-mount for
chroot(2) gaols, I don't think it will, because we want to control
things on an individual inode basis. Controlling things at the
directory (driver) level is too coarse-grained. Think /dev/null and
/dev/mem: both come from the same driver, both live in the same
directory.
What we need is a type of unionising overlay FS.
Regards,
Richard....
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
