Bill Studenmund wrote:
>>> | Which brings us to the question about recycling obsolete device numbers.
>>> | Should we do that or not and what is the downside if we do it?
>>> | 
>>> | I think we could recycle it at one point, which could be one or two major
>>> | releases after it was removed.
>>>       
>> I would like to get some comments about this point.
>> Is it ok, or should we keep the obsolete device numbers for a longer time?
>>     
>
> I'd say two or three. Or more. I don't think we are cramped for majors at 
> the present time, and if we re-use a major, we MUST make sure admins wipe 
> out the old device nodes. Otherwise /dev/vinum0d points to the device that 
> re-used the major, and the permissions may be all wrong.
>   
This problem really says that we need a real devfs that doesn't suffer
this problem.  Admins should not have to worry about major numbers.

In fact, major numbers should be totally dynamically allocated, and
never ever used from anything in userland.

The fact that we still use statically assigned major numbers is one of
the areas where we're still using 1970s technology, and its an inferior
solution.

If you think about device nodes, you really have a few device properties
that are interesting:

1) device path (this would be Solaris' /devices path), this is a fixed
quantity that is determined by the hardware, is independent of probe
order, and generally never changes -- it will include things like SCSI
IDs or WWNs, PCI bus/device/function information, etc.

2) device driver name

3) device "instance"  (e.g. is it com0 or com1)

4) device minor number (e.g. call-out vs. direct attached serial lines)

5) the "class" of device, e.g. "ethernet" vs "serial port" vs "scsi hba"

The various /dev/ nodes are just friendly names to get to these.  What
we need from a devfs is:

    1) a way to record for a given device path (#1 above) a persistent
"instance" number (see /etc/path_to_inst on Solaris)

    2) a way to figure out a reasonable /dev/ path name for a given
driver/instance/minor

    3) physically exporting the /dev/ path via special character/block
devices (e.g. a special devfs filesystem)

There are some tricky bits, especially with hotplug devices like
PCMCIA.  E.g. what happens when you plug a NIC that is identical in to a
slot, and that NIC is identical in all respects to the previous occupant
of the slot, except it has a different MAC address.

The other surprising result that could catch people off guard is that
e.g. in the first PCMCIA slot the device is known as "ne0" but in the
second slot it become "ne1", even if slot 0 is not occupied.

One possible snafu, is chroot()'d filesystems, where you only want to
expose device nodes for certain "safe" devices.  Maybe achieve this with
some kind of autofs or unionfs hackery?

To make devfs in general happen, as I see it, we need the following:

config_attach_sm_loc() needs to have logic to assign a major number for
a driver if one is not already assigned.  This needs to go into some
master hash table in the kernel (or resizeable array), protected by a lock.

each driver needs to properly publish either a device class (from which
a standard driver/instance -> /dev/ path list can be drived), or export
a subroutine to provide the mapping dynamically.

Interestingly enough, for standard kinds of classes, a real devfs like
this could export /dev nodes that are generic, rather than having the
driver name in them.

E.g. you could have "/dev/eth0" or somesuch instead of "/dev/ne0".

To get to logical names though you'd need another persistent table,
containing the logic name & instance mapping to the driver name/instance
number.

Btw, when I say "instance" above, I think I'm referring to the dv_unit
member of struct device.  I'm just used to the Solaris naming
convention. :-)

So, is anyone working on this?  Anyone *not* want something like this in
NetBSD?

    -- Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191