Subject: Re: devfs, was Re: ptyfs fully working now...
To: Christos Zoulas <email@example.com>
From: Steven M. Bellovin <firstname.lastname@example.org>
Date: 11/12/2004 22:18:46
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