[cc list trimmed]

On 2005-10-26 wrstuden@NetBSD.org wrote:
> Part of the reason I think we shouldn't support both devfs and no-devfs is
> that one huge point of devfs is that we no longer need to worry about
> explicit major numbers. I don't see how we can really support that with a
> no-devfs world. All the thoughts that come to mind seem like they are
> equivalent to really locked-down devfs environments. So let's just lock
> down devfs and be done with it. :-)

  I generally agree with this, however I also think there should be a
means of number to name mapping that can be used to support traditional
device nodes (but no longer having standard numbering).

  My basic problem with your way of looking at devfs is that you put
significant responsibility for device organization into devfs itself
rather than exposing kernel organization.  IMO, user organization is
likely to have kernel meaning as well, so the focus should be how to
organize devices in kernel such that a "categorized probe order" has
meaning to userland and can be directly exported as cannonical device
reference.

  It should then also be possible to import (at least some kinds of)
kernel configuration changes to a running kernel, to avoid the need to
reboot to wire down a device.

  It seems to me that the basic step necessary for any type of device
existence aware devfs is to separate lookup from open and provide event
notification for use by the file systems (which would keep a struct device
reference instead of device number).  This would still be usable with
number to name mappings, but with the mapping done in a different place
(outside individual drivers).

Matthew Orgass
darkstar@city-net.com