Thus spake der Mouse ("dM> ") sometime Today...

dM> >>> [...devfs...where to keep metadata...]
dM> >> [K]eep the metadata in a file.
dM> > Also, it should probably make some effort to rewrite it as a db so
dM> > that it can do a keymatch and overwrite an entry instead of having to
dM> > rewrite an entire file.
dM>
dM> ...with all the race conditions that implies. :-/  (You do _not_ want
dM> to destroy all of /dev just because you lost power halfway thorugh
dM> rewriting the file.)

So write to a temp file and mv when done.

dM>
dM> > 	/dev mounts on devfs
dM> > 	devfs driver updates from /etc/devfs.db
dM>
dM> Actually, it occurs to me: the logical way for this to work is
dM>
dM> 	mount -t devfs /etc/devfs.db /dev

Keep in mind that /dev is not solely the .db file; it is the core devices
MODIFIED by the .db file (i.e. a union).

- chown(2) and chmod(2) are VFS-safe, right?  i.e. they behave differently
  on different fstypes...?

If that's the case, a devfs is nothing more than a glorified tmpfs.

The trick is allocating sufficient space to the fs in the first place.

Maybe this is something to consider...shouldn't be too hard.

				--*greywolf;
--
NetBSD: You can't handle it.