devfs
[Top] [All Lists]

Re: devfs and device name persistance

To: Richard Gooch <rgooch@xxxxxxxxxxxxxxx>
Subject: Re: devfs and device name persistance
From: Johannes Erdfelt <jerdfelt@xxxxxxxxxxx>
Date: Mon, 8 May 2000 23:04:59 -0700
Cc: devfs@xxxxxxxxxxx
In-reply-to: <200005090534.e495YQ910398@vindaloo.ras.ucalgary.ca>; from rgooch@ras.ucalgary.ca on Mon, May 08, 2000 at 11:34:26PM -0600
References: <20000508221945.A1842@valinux.com> <200005090534.e495YQ910398@vindaloo.ras.ucalgary.ca>
Sender: owner-devfs@xxxxxxxxxxx
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?

It would be a win to move this to userspace versus the kernel where it is
now.

This has the added benefit of choosing names intelligently.

> > 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?

> > 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.

JE


<Prev in Thread] Current Thread [Next in Thread>