[Very late reply: I'm working backwards through my overflowing inbox]
Johannes Erdfelt writes:
> On Mon, May 08, 2000, Richard Gooch <rgooch@xxxxxxxxxxxxxxx> wrote:
> > Johannes Erdfelt writes:
> > > With more and more Hot Swap device busses becoming common, naming of
> > > devices
> > > is starting to become a problem.
> > >
> > > As an example, I'll use 2 USB floppy drives. Since they are floppy drives,
> > > the media and thusly filesystems can change frequently.
> > [...]
> > > The first problem is being able to differentiate between similar
> > > devices. USB has the notion of a serial number, however not all
> > > devices provide one. Most storage devices do however, which is the
> > > reason I'm using floppies as my example.
> > >
> > > Now that we have a unique way of differentiating 2 seemingly identical
> > > devices, our next problem is how to store this information. This is
> > > where devfsd comes in. I'd like to use devfsd to track this information.
> > > How it does this is not too important right now.
> > >
> > > The last problem is name space conflict.
> > >
> > > There may be a real device called /dev/floppy0. A possible solution
> > > that has been discussed is to mount the devfs filesystem on /devices
> > > (completely aribtrary name) and create symlinks between the virtual
> > > names on /dev to the physical names on /devices.
> >
> > I think any move that promotes mounting devfs elsewhere is going to
> > come back and hurt us in the future. /dev should be the only place
> > that applications (and administrators) look for device files. As soon
> > as we start seeing people (distributions) mounting devfs on /devfs, we
> > will see applications looking in multiple places for device
> > nodes. This will inevitably cause confusion, and once done, will be
> > very hard to fix.
> >
> > And having a pile of symlinks doesn't really solve the namespace
> > problem, because you can always come up with some name that will
> > conflict. And besides, a /dev full of symlinks is going to be
> > butt-ugly.
> >
> > I think the only solution to namespace conflicts is to admit that it
> > is real and has to be dealt with firmly. This means coming up with a
> > policy and "enforcing" it (i.e. various utilities follow that policy
> > and if you try and change it and it breaks, you get to keep the
> > pieces).
> >
> > However, it probably makes sense to put *all* USB devices under
> > /dev/usb, just like the SCSI and IDE trees.
>
> Most people are interested in the function rather than the connection.
>
> Very similar to how devfs currently create a /dev/discs which has all of
> the disks on the system. It's an abstracted directory of all disks
> regardless of it's connection (scsi, ide, usb, etc)
>
> Why cannot this be managed by devfsd?
I'd prefer the kernel manages device-type directories like
/dev/cdroms. It's definately nicer for the root FS on such a
device. And it's easier for the kernel to manage it.
> It would be a win to move this to userspace versus the kernel where
> it is now.
You could make the same argument for /dev/discs and /dev/cdroms. In
fact it's easier to let the kernel do it.
> This has the added benefit of choosing names intelligently.
I don't think device-type names should be chosen "intelligently". The
simple numerical sequence is fine. If you want some other kind of
name, then that can be managed by devfsd. But the kernel should
provide a simple namespace you can rely on.
> > > What I'd like to get is some opinions on this. I have a reservation
> > > towards putting so much into devfsd. I fear it may become too
> > > complicated.
> >
> > Also, I'd want to avoid "solutions" that are really only partial
> > solutions. I think we should just bite the bullet on namespace policy.
>
> I'm not exactly sure I understand what you mean. Is there a current
> problem you're referring to?
I'm referring more to "solutions" like scsidev, which only solve part
of the problem, and other alternatives proposed as a way of limping
along so that devfs can be avoided at all costs.
> > > Also, not all devices can be differentiated. However, we can do some
> > > things. For instance, we can determine which port a device is
> > > plugged into and create a topology tree. This way, we can
> > > differentiate 2 mice. However, if the device is moved to another
> > > port, the mouse would be "new".
> >
> > Yep. Not much to be done about that.
>
> Well, I'd like to offer it as an option to use that algorithm. Many
> OS' currently do like Windows and BeOS.
If you have an algorithm, then fine, create a new namespace. But we
should still keep a simple kernel namespace. The kernel namespace will
work fine for people with only 1 of each type of device, and will work
without the need for devfsd.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|