Subject: Re: devfs, was Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
To: Matthew Orgass <>
From: Bill Studenmund <>
List: tech-kern
Date: 10/27/2005 15:41:53
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 27, 2005 at 05:40:51PM -0400, Matthew Orgass wrote:
> [cc list trimmed]
> On 2005-10-26 wrote:
> > Part of the reason I think we shouldn't support both devfs and no-devfs=
> > 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=
> > 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).


Once we have devfs, why bother with traditional device nodes, other than=20
to support NFS exporting /dev to older systems?

I do see an advantage to having multiple /dev mounts so that chroot=20
environments can have devices. I think that came up as a MUST last time we=
hashed this out.

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

To be honest, I have the feeling you are discussing details that are finer=
than the hand-wavyness we currently are at. So it may be premature to say=
that we disagree. :-) I think we're at the point where we need a white=20
board and a few beers to map stuff out.

How is "organize devices in kernel ..." different from wiring devices
down? We can do that now, and it kinda works and kinda doesn't. A number
of us don't like it (well see warts in it), and that's why we get ideas
about devfs and other things. :-)

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

As above, we may be not in disagreement. One idea I had was that if the=20
userland config file said SCSI disk wwn 52004567BA64678D was sd3, devfs=20
setup would make whatever disk had that wwn be sd3. I was even kicking=20
around the idea that kernel log messages would say "sd3" in them. This=20
idea is still vague, and for instance I haven't figured out what exactly=20
to do if we already had an sd3. :-)

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

Maybe I know too much about how file systems work, but I don't understand,=
"separate lookup from open." They are separate now...

What events would file systems be interested in and how would they use=20
them? My understanding is that the file systems won't care.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)