Date:        Thu, 18 Nov 2004 10:29:38 -0800
    From:        Bill Studenmund <wrstuden@NetBSD.org>
    Message-ID:  <20041118182938.GD8951@netbsd.org>

  | I uesd to think some idea using on-disk device nodes would work, but I
  | don't anymore. Why shouldn't we just synthesize the whole thing from
  | scratch?

I'm rather behind on my NetBSD mail (yet again), so maybe this has already
been discussed (in which case I will find it eventually) - but how are any
of the devfs schemes that have been tossed around proposing to handle the
various time fields from the (current) inodes?

ctime is probably not important (but that one would take some thinking about)
birthtime is uselsss in all cases (for all inode types, but that's not
relevant to this discussion), but knowing atime & mtime for some devices
is incredibly useful.   It isn't for ptys, so I don't care whether ptyfs
does anything with this (haven't yet tried it), but for printers, real
terminals, tapes, and some other stuff, knowing when it was last written to,
or read from, (even many reboots into the past) can be useful.

I mean, do I know my tape drive is still OK, when was the last time I
used it?   Hmm ... 18 months ago, then perhaps I shouldn't be relying upon
it working tomorrow...

Schemes which simply invent nodes (of some kind) at boot, even if they apply
owner/permission fixes from some file that holds this information, just
aren't good enough.   None of that kind of thing is suitable for holding
data that is subject to being updated (by the kernel) as frequently as an
inode atime.

If the only real rational for a devfs is to clean up clutter in /dev
(for those too lazy to cleanit up themselves, and who nevertheless care
about it), then I'd suggest not bothering if a side effect would be to
lose the information from the time fields.

kre