Re: [RFC] New Driver Model for 2.5

Mike Fedyk
2001-10-19T20:24:12Z

On Fri, Oct 19, 2001 at 10:07:39PM +0200, Tim Jansen wrote:
> On Friday 19 October 2001 21:21, you wrote:
> > > For example for harddisks. You usually want them to be mounted in the
> > > same directory.
> > When is /etc/fstab going to support this?
>
> You can use the device ids to provide stable symlinks, then /etc/fstab
> shouldn't be a problem.

Sounds good.

>Or you rewrite mount to support it. Or you do it in
> the kernel with a user-space helper: when a new device is connected its ID is
> sent to some user-space app, and the user-space app then assigns a minor
> number and devfs name to the node.
>

Or, just use autofs, it does pretty much what you're describing.

> IMHO using the path of a file in /dev to identify a device node does not work
> in a hotplugging environment. You need this to support existing apps, but the
> only way to be sure that you always get the same device is to use device IDs.

Actually, I don't have a hotplug envoronment, but that's not the only place
it would be useful. Does ide/scsi have reliably unique device IDs? If so,
once devfs gets rid of those races it would be very useful in a large raid
setup. Hmm, I guess that could be hot-pluggable with high end hardware.

> You could encode that device id in the node's path or use the path as a
> moniker for the device id (the symlink solution does this), but you need to
> have more information about the device than it's minor number (the X in
> /dev/lpX).
>

What does devfs do now?

>
> > >Or for ethernet adapters:
> > > because each is connected to a different network, so you need to assign
> > > different IP addresses to them.
> > I haven't seen anything assign ethX assign a certain order, except for
> > ordered module loading, and then if there are multiple devices with the
> > same driver, the order is chosen by bus scanning order, or module option.
>
> Ok, but I think no one doubts that it is a bad idea to assign ethX
> semi-randomly. Basically this is the same problem as with device files, only
> in a different namespace.
>

So is that in favor of changing the current ethX naming convention or not?

>
> > Does anyone know if devfs will, or has any plans to support any of the
> > above features?
>
> The device registry (www.tjansen.de/devreg) patches devfs to allow the things
> described above though.
>

Everything, with all of the ids? What about scsi/ide?