Date: Sat, 15 Aug 1998 00:07:41 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: drosih@rpi.edu (Garance A Drosihn) Cc: brett@lariat.org, rabtter@aye.net, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: 64-bit time_t Message-ID: <199808150007.RAA28867@usr04.primenet.com> In-Reply-To: <v04011701b1fa1b25b9b2@[128.113.24.47]> from "Garance A Drosihn" at Aug 14, 98 01:19:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I believe that Linux is already moving to a 64-bit time_t. The BSDs > > are behind. Maybe that's why there's resistance here (I can't figure > > out any LOGICAL reason for resisting this necessary change.) > > Just that it's work, and it's work which does not need to be done > right this second (so to speak). It will most likely be somewhat > disruptive work. Perhaps we should consider it for FreeBSD 4.0, > because (IMO) it does seem like a good thing to do "sometime". > But right now we have other projects we should concentrate on and > finish off (IMO) before opening this one up. > > (elf, SMP, perl5, softupdates, etc) The FS is going to be worst, mostly because of the quota code and some ill-considered changes which used up the spare fields. The quota code is broken (struct dqblk has no spaces in it). But the quota code needs to become a stacking layer anyway. The ufsmount struct is broken (in the quota code), but it's not an on-disk structure, so it doesn't need to change. The fs_time field in struct fs is broken, but the purpose of the last written time is to avoid the AppleTalk polling refresh, so it can be deprecated out as an int32_t "spare" field, and the real thing can be kept in the in core data fields that are never written out. If you need to keep it on disk (why?), then you can steal two of the adjacent 32 bit long fields that can be calculated from the other fields at mount time, and themselves kept incore instead. The struct cg and ocg cg_time field is a bit sticky. Probably it would be best to spare it out and take two adjacent 32 bit fields from cg_sparecon (which is 13 32 bit fields long and reserved for future use). This will only work for cg, not ocg. cg_cgx could be overridden, and abused as half of the time_t, since you could calculate this value as well. It's even in the right place for the byte order. Unless there is a pressing use for the struct fs/struct cg/struct ocg values except for them to monotonically increment (note: *not* "increase"), then it might even be worthwhile to just mask the low 32 bits from the time_t. Which leaves us with the non-POSIX struct timespec, which ate our beloved spare longs which were put there for expanding time_t in the year 2038, and stolen by some nasty person to store useless nanoseconds (breaking stat's Y2039 compliance at the same time). Back out the timespec crap, and the FS should be easily convertable, leaving only the issues that Sun was kind enough to document for us: http://www.sun.com/y2000/strategy.html Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808150007.RAA28867>