> My thoughts were that, with the binary file idea, we have explicit
> atime, mtime, and ctime fields.  When the node gets updated, we note
> the change and mark the internal entry dirty.  [...]

Now, I have a question.

At this point we are inventing a naming scheme for devices (so that
changes of, eg, mode, or mtime) can be associated with the same device
on subsequent reboots, stored somewhere, and read back next boot.

At this point, I feel forced to ask: what benefits does this devfs
offer over simply redesigning device nodes to use this new naming
scheme instead of the <major,minor> naming scheme we've been using so
far?  (I am not claiming there are no such benefits.  I'm just trying
to compare devfs against "simply" redesigning device special files,
which latter would automatically preserve many of the things we've had
to worry about devfs preserving, such as traditional semantics for
calls like chown and chmod.)

In particular, I'm comparing, in my head, devfs versus redesigned
device nodes plus a script/program that deals with devices that appear
or disappear (as compared to the previous state); each one has its
strengths and weaknesses, and I'm interested in our making as informed
a comparison as we can.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B