Date: Wed, 23 Aug 2000 20:51:28 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Siobhan Patricia Lynch <trish@bsdunix.net> Cc: freebsd-current@FreeBSD.ORG Subject: Re: weirdness with devfs? (time) Message-ID: <4852.967056688@critter> In-Reply-To: Your message of "Wed, 23 Aug 2000 14:35:58 EDT." <Pine.BSO.4.21.0008231435260.21752-100000@superconductor.rush.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSO.4.21.0008231435260.21752-100000@superconductor.rush.net>,
Siobhan Patricia Lynch writes:
>On Wed, 23 Aug 2000, Poul-Henning Kamp wrote:
>
>> In message <Pine.BSO.4.21.0008231025570.21752-100000@superconductor.rush.net>,
>> Siobhan Patricia Lynch writes:
>> >this is cute:
>> >notice the dates, they predate the epoch.
>>
>> Because of your timezone.
>>
>
>nod, figured that out already, however, is the epoch date intentional?
No.
I'm working on that issue right now.
If you look in sys/ufs/ufs/ufs_vnops.c:ufs_spec{read|write}() you will
see that the filesystem "hosting" the device node has to figure out
for itself when to update the ACCESS, UPDATE and CHANGE timestamps
relative to the access to the dev_t through specfs.
Obviously wrong since all device node hosting filesystems (ufs,
ext2fs, devfs cd9660 (well, not really but in principle...)) will
have to duplicate that code.
I'm looking at a patch right now which adds three flag bits to the
dev_t and clone this code into sys/miscfs/specfs() where it will
maintain these three bits. The hosting filesystem can then examine
just those bits to determine when timestamps should be updated.
The advantage to this scheme is that the drivers themselves can set
these bits when for instance ioctl functions have "updated" or
"accessed" the device.
The secondary advantage is that we don't have to have this code
mutated in multiple filesystems.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4852.967056688>