-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As some of you may know I've been working devfs support for NetBSD as
part of a project for my final year at the University of Leeds.

The project exists on the mjf-devfs2 branch in cvs and is at the point
now where I need some testing from people other than myself. However,
I must warn you that this branch is still highly experimental and many
device drivers have not been converted to the new world order of
device node registration, which means that if you mount a devfs over
/dev (which happens by default unless you turn off devfs support at
boot with the -n option) some device nodes that you may need, will
not appear. I intend to continue converting device drivers on this
branch and if anyone wants to write patches for device drivers and
send them to me, I'd really appreciate it.

To test you can either build a distribution from the mjf-devfs2 branch
and do a fresh install, which is the recommended way, or drop the userland 
applications (devfsd, mount_devfs) onto a current userland and run a 
devfs-kernel. The problem with the second approach is that you can't replace
/sbin/init with the patched version on the mjf-devfs2 branch and so, if
you ever need to do any maintenance work in single-user mode whilst running
your devfs kernel, you will have to manually run devfsd -s, otherwise
/dev will not be populated with device nodes.

In the kernel config you must add some options,

file-system	DEVFS
pseudo-device	dctl


Now, onto the design. My devfs implementation consists of 3 parts,
	* devfsd: the userland daemon that controls the naming policy
		  of devfs.
	* devfs: the file system code for the device file system.
	* dctl: the devfs control device node that allows devfsd to
		communicate with and manipulate devfs mounts. This
		device node is also responsible for notifying devfsd of
		new devices being attached to the system.

devfsd reads a configuration file when it starts up and this config file 
contains rules that gove...
[ message continues ]

It seems like a lot of this naturally belongs in the device switch and that
the same call should register the device methods. Are you proposing to keep
the existing major numbers? That makes sense in the short term but longer
term I think we'd be making a mistake by doing that.

Thanks,
Andrew

For now, the idea's to stick with current numbers. Adding a device switch=
=20
table as part of the request for a new major number, however, makes sense.

=46rom the point of view of the devfs code, major numbers are just things=
=20
that are there. The code will work w/ static majors or with dynamic=20
majors. I think we'll need this code (devfs) to really make dynamic majors=
=20
work, but they are otherwise unrelated.

Take care,

Bill

While there, think how to avoid the issue with Solaris and name_to_major
in cluster environment sooner than we actually get cluster support.  :)

If you don't know what I am talking about, try:
 http://www.google.com/search?q=3Dsolaris=F2ame_to_major=E8luster


--=20
-- Lubomir Sedlacik <salo@{NetBSD,Xtrmntr,silcnet}.org>   --

Something got lost in translation above.

As best I can tell, the above's a consequence of how Solaris implemented=20
its dynamic device configuration.

I could be wrong, but I think what we have in mind is significantly
different, so that this issue doesn't really apply.

Take care,

Bill

make that=20

   http://www.google.com/search?q=3Dsolaris+name_to_major+cluster


--=20
-- Lubomir Sedlacik <salo@{NetBSD,Xtrmntr,silcnet}.org>   --

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I haven't yet looked into this fully, mainly because it's the last stage
of the project. However, mrg has pointed out that we already support
dynamically assigning major numbers because the switch tables can be built
dynamically at run time. If I recall correctly he mentioned he made this
work with LKMs.

When we make the switch I wasn't proposing to keep the existing major
numbers, I'm not aware of any problems that would be introduced by having
different ones. That's not to say there won't be any. As long the upgrade
procedure for new devfs installs is sane and we can take account of 
people's customisations of device nodes, everything _should_ be fine.

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

iQEcBAEBAgAGBQJH8iU9AAoJEK3y1f69VxYbNZUIALk773cZsLUz8ImK/LubZ78Q
d220Y4UftqawlyOOCz9OOax2vKaXwmTs7pyeG2JTV2i/KSciDEk/hcbKHqCH1dLu
u2+SJc210quUMC/H9Voq2vFV3suEFeKvnLsTw12KlXtUXtsQZW8MWQ/fyzaaISH3
OVAFHg9Rj32SDOhlkjFHW7LEVs5XP7vKAB95HQylGE32CoTaE9lISraLHE95sLFI
lGR7mKCtmd+N3fXt3YeCyJXe2Gw0D+wZjBffbzr9TKsdxhiY+hvmBOCsmD16lrsp
HesqcxXHOMJd5W4u5s5BZ90OaK79Pnz7lrjhsldIob/dH01p2Alp3qbht4Vsodk=
=bgLk
-----END PGP SIGNATURE-----

I haven't yet looked into this fully, mainly because it's the last stage
   of the project. However, mrg has pointed out that we already support
   dynamically assigning major numbers because the switch tables can be built
   dynamically at run time. If I recall correctly he mentioned he made this
   work with LKMs.

just to be clear and not take others work as my own, i didn't do
more than make vnd(4) LKM use it.  other developers changes to
devsw interfaces made it possible to do in a sane/portable fashion
without hard coding every platforms major/minor for vnd(4).


.mrg.

Woot!


You need to add something to indicate if the dev_t is a character or block=
=20

Ok, while I can see the need for an unregister_name(), I think what you
really want is device_unregister_all(dev_t, is_block) which zapps
everything for that device.

Saves snprintf()s in detatch. :-)

Actually, if you pass in the device_t, just have=20

Take care,

Bill

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



That's a good point. Device names aren't going to be detached unless they
have a device_t. Though perhaps LKMs may not be backed by a device_t but
still may need their device node removed? I can't think of one off the
top of my head, but I'm sure someone can ;-)

device_unregister_all() however, is a winner. I'll add that func.

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

iQEcBAEBAgAGBQJH8TQMAAoJEK3y1f69VxYbB7UIALWBXw3d0oztu2JYb0uGXehb
DivlIOKZHn+khhfyR9SvcLURjzScxVja7rp/bgYuajxyREMm2xnrgj07BC25sMTU
WKWrDVPZhkgWxTc3h8h1Flnc9AA4CjrD8g8NUzt6ptmFdebjXUygirQ3pThgYW9+
6ntI0UAWNe8bHqjcZ3sKI4MWzLngn7fGvXVMIsmB2w2XcJgv6JCUdERKFI1rmaBD
7klEBXNOhK1AN9paBnZUrQyVuAp1cgkz+8++kvd3DQ8I5mREgMCX4MXuikNwTquo
UVvI1rKpcTwH8/snCCMSE/OInCRv7eiqV6ciZ2QZ507R+dDJPTIrFbb143FN7OA=
=J6j+
-----END PGP SIGNATURE-----

I think block devices should just go away.  Wouldn't this be an opportune
time, too?

Thor

I don't think so. There are a lot of things to get right here, so I'd like=
=20
us to do one thing at a time.

I also am not yet convinced we should get rid of block devices, so I=20
definitely don't want to link the two actions. :-)

Take care,

Bill

On Monday, 31 Mar 2008 1:54:24

Would this mean that there could no longer be fast read-ahead and
cached disk device access?
-- 
Matthew Mondor

Block devices don't give you that now.  They access the _metadata_
cache -- it no longer holds file data, and the allocation scheme it
uses now is utterly performance-destroying if you try to use a block
device from userspace to get cached access to the underlying disk
drive.

-- 
  Thor Lancelot Simon	                                     tls@rek.tjls.com

  "The inconsistency is startling, though admittedly, if consistency is to
   be abandoned or transcended, there is no problem."	      - Noam Chomsky

Thanks for the explanation,  I had the misconception that disk blocks
accessed via block devices were always directly added in the buffer
cache.

-- 
Matthew Mondor

I doubt it. While I do not know all that Thor has in mind, I doubt he's=20
going to propose getting rid of read-ahead or caching. To be honest, we=20
aren't getting rid of read-ahead or caching, so I really doubt that's what=
=20
Thor has in mind. :-)

Take care,

Bill

The first names coming to my mind when thinking about a control node
would be "devfsctl" or "devctl". Why did you choose dctl?

ciao
     Klaus

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


"devfsctl" seems rather long, "devctl" seems ok but we aren't really
controlling devices. I don't particularly care what it's called. If a few
more people pick one of your choices, I'll switch.

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

iQEcBAEBAgAGBQJH72tVAAoJEK3y1f69VxYb3ZMH/R25mjXkIaSXeJlUd8fHtDUa
667qDkVRUpWerwcdc9FR5IZXiCiIiJTHQlhq66taxCtQiavDvuVCPAXU4dsc88uV
6m3XiDZrDPJ5tCD4ldPaNqfPsq14YqZvtx8sWroXJz9ZelG+2r7CQNQ0mRVWRcKD
61CEN1PjIEYR/VFdDRKRvvBRmwzCvvoG85tRyiJ7fdLVWEMN0WhRciySuRuev8IE
rnmlIeYVebq2EALsM2G5RRy7HQvmnMfTJgu9/Flj3H0R41nfXayLN3Zhk79RoRZh
K5vTvhCtdkP0ZI0fRJqC29kAgF3htCnEbwZuc8ga8SQs+eZgi42BtgTFfk4MGuw=
=G3rw
-----END PGP SIGNATURE-----

I think I'd pick devfsctl.  This is not something people will be typing
regularly, so I can't see that length makes much difference; to me, it
is by far outweighed by the clarity of devfsctl vs dctl or even devctl.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

On Sun, 30 Mar 2008 10:31:41 -0400 (EDT)
I agree.  "devctl" sounds more generic.  If you really can't deal with
the extra two letters, use dfsctl, but I'd prefer devfsctl.


		--Steve Bellovin, http://www.cs.columbia.edu/~smb

I'll see your "devfsctl", and raise you a "*_deregister_*".

But these are nits - when it comes down to discussions about the
names, then you know we're almost there.

I am *so* looking forward to having devfs in-tree - thanks, Matt for
providing this.

Best,
Alistair

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


devfsctl it is. There'll also be some man pages getting committed soon,

My pleasure, Al! I'm sure iSCSI will be able to make use of it.

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

iQEcBAEBAgAGBQJH7+9wAAoJEK3y1f69VxYbq9EH/2kujXL9zq+8Phoe362M4xbm
Gth3CDIfuRMS4O3LyKuvBya482aUs90IO46+ph+ZnYCVs/go9f1u8Kdv23Lv8/xG
phExGR52biMFtPwyUaouR/9T50jq30CR7Dco0UA9oYgMynIiXPSMFvR6ZzhdHjfb
9Uns4SZY6WrSGaChG9icY/Bl1q9wD22SPHriV2wJ0kEPWHrwoSD5KRoBTuZT2goa
sq6sJ00LDEH+iv+ivho1GevjMTGprSjHowhrPUhpzy8H3SUfj7kQ9DjhNqGyZkZx
+jMxNg3qoCJnZgh1M7L+RZmEW8ETNbg55u54x0c4SA5CKzSQxX62U2yydCi7Cb4=
=smnt
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,


I don't have a strong opinion here but I'd prefer devfsctl because it  
seems more obvious, natural and in line with things like raidctl,  
wsconsctl, scsictl and so on. With <drivername>ctl there's no room  
for ambiguity, which is a good thing IMHO.

have fun
Michael

PS: it should be green ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBR++ftcpnzkX8Yg2nAQI2qAf9EFgqgPYzz6CcdNGR1Xcj1zWchSXOtw6P
/t6MKvBu86KaO+7vbMmnsxciiJrIBsh9T/TN1fWC3T6RMMeMBN6kiadYsrfPAZGM
Q0UmVkh88JKY0YYmanYVBdAbZbJHOE2UEGizR+hOGljME8Uj0JnF/eOGLYV/0WtN
M0Nm5sGGUFQ7cbA/hIvW5a/+rJGcG1eAQEw2PRSu63+DOgBp4XmOKf7QZy59TkPY
jBa28xdO2CP+1QN0rXHqm61Pbrpe/tR7NzAcoiks2p2NniWN0IfHRi4vY3AtkYx7
iP19NOXuliROgNlqz3IfmFlwTmHiMA8n/QgNn1xYgxLQw29N90cblQ==
=Th/d
-----END PGP SIGNATURE-----

First off, I would like to thank you for this work Matt! I'm very 

Does dctl notify on all autoconfiguration attach/detaches, or only on 
new device node additions/removals? If the former, I would really like 
to use this facility for device notifications with my NetBSD FDO HAL port.

Cheers,
Jared

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


dctl notifies whenever a driver is attached to a device. It is devfsd that
controls device node additions/removals. It'd probably be best to expand
dctl to handle multiple listeners which FDO HAL could use.

I'll keep you posted.

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

iQEcBAEBAgAGBQJH7sTiAAoJEK3y1f69VxYbxtUH/2iclswUDWRJHevUW7e2miV3
Occl680thlR6zNJLsTqFEXKLRZcnuFwrzYfYGmIfK4mJeYRS9+zL6oaS9hpAq6gl
7VqBWRM43COk4jdJmITZ7t4zb28KZty41hObNtg2AWzDTEb6IRa6G8RHrVDDPsQh
IYTBTeetH/YUXfdKWeFJdijLGIaJhxhrmTJg/WvJE6C75JpB+lerzsv01IJrpUwr
DzXlGf1n5HmW20lKJyc314x/8DDgrdXYCsNMKGJ05GVW3sL7dR6wL6ED4v+ZJFUG
k6uxjOs6B9syuIAO086Vevf5xGhCLhxnjErfunDidIr+FMnA4NvpecAce7rz/+E=
=uqVO
-----END PGP SIGNATURE-----

Thank you Matt.

Cheers,
Jared

On Saturday, 29 Mar 2008 12:33:05
[...]

I very much like the fact that policies can be specified for
visibility and accessibility.  Previous resistance to devfs adoption
on NetBSD was usually related to the lack of such features in previous
attempts if I remember...

I admit I'm not familiar with autoconf enough, and that initially it
is ideal for changes to not be invasive into existing frameworks, but
would a possible slight modification to autoconf allow unchanged
driver code to work with the framework?

Thanks for the great work,
-- 
Matthew Mondor

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Yes, perhaps. It made more sense to me to be more invasive so that each
driver has complete control over their own device node, because some
device drivers require multiple device nodes whose names aren't obvious
from the driver name, tty and wscons code codes to mind. In other words,
there isn't a 1:1 mapping between device drivers and device nodes, you

Thank you for the support.

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

iQEcBAEBAgAGBQJH7sduAAoJEK3y1f69VxYb8w0H/1/+4W1YaHllpjw90Gc2EPei
M5Yp8vNHn9w/d/Nyp+GuMUiBU+jat5P7JBZ5ES7h4zC+LU9EMEoyVOhYHO4jNhmd
ZXtQjBrFt/F06g9SPxPxWxVajeb2YHhOU4lElhgiict/iLCO3occ0oRZMKlU1OpG
SGowQSwwrA6iTGcL1DFTz2UW0rJlLVHu+yRALsMGLrGcggMihSX8pAJCYq1DUd5z
BXyo85/eQLeoXwoEzmG2/8xs4Mx0XzL01bgbLXZy8UIkeDvy8sKDbf8WCfVv+NGG
fg+63hsi23Bx/hcDomTBBldRRIlbapojTs5wWsRAKgMk1e92L/0ZICgoM5ODByQ=
=RnoO
-----END PGP SIGNATURE-----

> [...devfs...]

Somkething like this has been needed for a long time.  A very cool use
of the flexibility of custom filesystems.


...leads me to ask, what about other things, such as mv, ln, ln -s, and
objects other than device files in /dev?  While I can't speak for
anyone other than myself, I don't consider support for that sort of
thing in /dev optional (for other than devfs-development systems).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Well, I happened to leave out mv from the above point, but it was supposed
to be included, as a mv action just specifies a new filename to be applied
for a device node.

I hadn't thought about ln, but I guess it's like specifying another 
filename for that device node. You also only need the link around when
the device is actually on the system. So, it's definitely possible to
implement this, but I admit wasn't something I'd actually thought about.
Thanks for bringing it up, I'll add it to the TODO.

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

iQEcBAEBAgAGBQJH7plSAAoJEK3y1f69VxYbGAoH/1NdL2UN2p8oODIUHTQhu3ti
llXPtnUIKgnLMsqDsTrt5K9gSAIA1V0kqZWl48+mVisSFY+/jrqtZv21HV+Bogl/
0MI6/rSLMkTTvJTbdrPtWa9yN9V+3bjPpLNmxs9nGzfO3itg2GXf51UpBKgeX2FO
5qrm5HGymmOdVtfyqZNGEAhUL0fpm97on6FV6y4FnZiBGe5lCNOwVl2hEbYgB62m
IXzyU9EpVjri+0Pm2V/rVWqYqrvTIOeZPz0j/KFge7fg/kkENcndfhwLKw9S2I5a
BjXmVWSBz8oa1yEm2386kyDRDlnwn1Nvwi5zo6VlHbaM3kXtoZJ7AKKuhS06DiY=
=gmKE
-----END PGP SIGNATURE-----

Yes, but with an important difference.  "mknod foo c x y; ln foo bar"
and "mknod foo c x y; mknod bar c x y" produce subtly different
results: in particular, consider which nodes are affected when tools
such as chmod or chown are applied to one of them.

Is this difference actually important enough in practice to be worth
implementing?  I don't know.  I have no real idea how hard it is to do;
it's also something I personally use relatively seldom - but it does
seem to me that trying to explain why it works differently in /dev from

Well...maybe.  That certainly should be the default, it seems to me,
but I'm not convinced the alternative is useless.  (It may be close
enough to useless to be not worth doing, to be sure - especially in
view of the possibility of creating device nodes in the underlying /dev
and mounting devfs with -o union.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B