From the laudably twisted mind of Steven M. Bellovin comes:

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

Ooh, I *like* it.  It's just weird enough to appeal to me in a warped kind of
way.  All the device nodes are really there on the disk, and the job of devfs
is to *hide* the ones you *shouldn't* see.  You're a sick man.  I mean that in
a good way.

But it seems the one detail that overlooks is (as others have pointed out)
it doesn't make major/minor numbers a thing of the past, as a more quotidian
devfs would.

How about putting one more odd kink in it?  The drivers don't create the nodes
on disk, they just appear magically in devfs as you would expect.  But when
you chmod/chown/etc. any of them, *then* a shadow entry is created on the disk
beneath the mount point (sort of like a union fs upside down) and the owner/mode
replicated there.  It doesn't matter what the major/minor numbers are in the
shadow entry, it's only there to carry owner/mode/flags info.  It could have
maj/min 0,0 or -1,-1 or whatever, it really doesn't even have to be c or b
entry type (though probably least confusing if it is).

Now the entries devfs shows you are exactly the ones magically created in
kernel, but with the attributes of a matching entry beneath it on disk if
one exists, default attributes otherwise.  It does not show you any of the
entries on disk when there is no live devfs entry corresponding.

If you also arrange for symlink creation also to go to the disk beneath,
then the admin can just create symlinks too in the usual way and they should
Just Work.  Hard links would be a little more work, but if one of the entries
matches a live devfs node by name you could make the others be recognized as
hard links to it if that would be desirable.

Hm, maybe being fried from IETF is just what it takes to come up with those
cool twisted ideas.

-Chap