--n2Pv11Ogg/Ox8ay5
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:
>=20
> [cc list trimmed]
>=20
> 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. :-)
>=20
>   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).

Why?

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=
=20
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=
=20
than the hand-wavyness we currently are at. So it may be premature to say=
=20
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,=
=20
"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,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFDYVexWz+3JHUci9cRAnbjAJ0faNXQOTrWRgKqNJVb1qWdw6Yv6gCgkpMh
jC7v9oWaqGv5lVxPPlqbs7A=
=mj5a
-----END PGP SIGNATURE-----

--n2Pv11Ogg/Ox8ay5--