In message <20041113020824.CCE652AC7B@beowulf.gw.com>, Christos Zoulas writes:

>
>Here's what I've been thinking. At boot time, you pass the mount struct
>of devfs a filename which contains a list of commands to be applied to
>it before it gets mounted. These have plain unix syntax and they can be
>
>chown id:id name	# change ownership to a configured node
>chmod mode name		# change permissions to a configured node
>rm name			# whiteout a configured node
>ln -s name		# make a symlink to an configured node if it exists
>mkdir name		# create a directory
>mknod name [b|c M M] [p]# create a node, for sockets we just create them.
>
This is all pretty convoluted.  Let me phrase the question this way: 
what problem does this solve?  I see two possibilities: it keeps /dev 
from being cluttered with non-existent nodes, and it avoids the 
necessity of having to create nodes when a new device is added.  Let me 
suggest a simpler devfs that will avoid the need for this file.

Indeed have a devfs.  At boot time, though, before anything at 
userlevel is run and before devfs is mounted, each device driver 
verifies that its /dev entries exist.  Any that don't exist --
this can be table-driven, with parameters describing what nodes are
to be created.  That solves the second problem.  The first problem is 
solved by a devfs layer that, before returning any device inode, 
verifies that it exists in the running system.

fsck is a bit of a problem in this scheme, since you shouldn't create 
inodes on a dirty file system.  One solution is to overlay-mount an MFS 
on /dev if / is dirty.

I haven't thought through all the details (and I'm more than slightly 
fried from being at the IETF all week), so there are probably plenty of 
other holes I've missed.  But I think my first question stands: what 
problem does devfs solve?

		--Steve Bellovin, http://www.research.att.com/~smb