--huq684BweRXVnRxX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 26, 2004 at 04:08:09PM +0700, Robert Elz wrote:
>     Date:        Thu, 18 Nov 2004 10:29:38 -0800
>     From:        Bill Studenmund <wrstuden@NetBSD.org>
>     Message-ID:  <20041118182938.GD8951@netbsd.org>
>=20
>   | 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?
>=20
> 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?

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=20
and mark the internal entry dirty. We then either immediately write the=20
data out, or write it out say once every minute. Thus we keep stat info=20
around.

> ctime is probably not important (but that one would take some thinking ab=
out)
> 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.

Agreed.

> 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...
>=20
> Schemes which simply invent nodes (of some kind) at boot, even if they ap=
ply
> 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.

Why is getting info from a file insufficient for keeping track of inode=20
atime? Obviously we have to have a field that includes the data, but once=
=20
we do, how is there a problem?

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

I think we want devfs for much more than just reducing clutter. The main=20
reason I'd like a devfs is so that we can maintain device permissions and=
=20
info that is independent of major & minor number. While major number will=
=20
probably not change and we have ways of tying minor numbers down, it would=
=20
be nice to be able to tie device identity (and permissions and access=20
times and ownership) down in ways we can't now.

Take care,

Bill

--huq684BweRXVnRxX
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFBqP3+Wz+3JHUci9cRAmjhAJwMujZhIGQUHZlxkWVTv7qr6SyxcACgg15H
tnTTDcIDurONaiJGHZSc6Lw=
=dScn
-----END PGP SIGNATURE-----

--huq684BweRXVnRxX--