Subject: Re: devfs, was Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
To: Matthew Orgass <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 10/27/2005 15:41:53
Content-Type: text/plain; charset=us-ascii
On Thu, Oct 27, 2005 at 05:40:51PM -0400, Matthew Orgass wrote:
> [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=
> > 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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----