On Nov 12, 10:18pm, smb@research.att.com ("Steven M. Bellovin") wrote:
-- Subject: Re: devfs, was Re: ptyfs fully working now...

| 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.

Where is that table? In userland or the kernel? What are the permissions
and ownerships for these devices? Can they change?

| 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.

You can always overlay an mfs. Actually we kind of do have with the kludge
to create the mfs /dev on demand from init if /dev/console is missing.

| 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?

As you mentioned:

1. keeps /dev from being cluttered with non-existent nodes.
2. avoids the problem of having to create new nodes when devices appear
   and deletes nodes when devices dissappear.
3. userland does not have to know about device major and minor numbers
   anymore like MAKEDEV does.

christos