Date: Wed, 19 Aug 1998 02:37:14 -0500 (CDT) From: Jim Bryant <jbryant@unix.tfs.net> To: tlambert@primenet.com (Terry Lambert) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: proposal to not change time_t Message-ID: <199808190737.CAA19503@unix.tfs.net> In-Reply-To: <199808190502.WAA01835@usr06.primenet.com> from Terry Lambert at "Aug 19, 98 05:02:21 am"
next in thread | previous in thread | raw e-mail | index | archive | help
In reply: > 1) Unbugger the nanosecond hack. > 2) Redo (or temporarily disable) the quota code. > 3) Change the cg and supperblock timestamps from time_t to > monotime32_t. > 4) Macro wrap all time_t accesses, taking into account byte order > and existing sparing issues. > 5) Define a manifest constant, because the CPP is too stupid to > handle "#ifdef (sizeof(x) == 32)" because the preprocessor > doesn't do what it's documentation says, and some lame-o > put the sizeof() preprocessor directive into the compiler. > 6) Rename time_t to xtime_t temporarily and compile the world > with all warnings on. Everywhere it complains about time_t, > put the reference macro. > 7) Rename xtime_t to time_t. Repeat the process. > 8) All time_t dependent system calls must change. Oh wait, that's > just stat(2) and fstat(2), and they already have overlay space > reserved for use by the declaration macros, once you do #1... > 9) Fix third party futilities, as necessary. > 10) Rejoice an be happy. > > > typedef long long int64; > > typedef int64 time64_t; > > time39_t time64(time64_t t); > > This is evil. Why not 64 bit everywhere? The only thing I can think > of is to preserve a hack with ill-thought-out consequences. 8-(. it may be a kludge, and i have said as much, with the assumption that the inode could indeed be modified further to make a new space for the nano-hack, and retain the upper 32 in the inodes for what it was intended for. the fell-swoop approach is not unprecedented under freebsd. all i am thinking of here is the userland code and DATA out there that will need a more gradual migration. another approach could indeed be the HP route to 64 bits. hp/ux 11.x is in two flavors, 32 and 64 bits. this could be nasty to maintain though, but given new guidelines for new code, it could be done, although kludgy. i have not disputed the fact that the filesystem would have to find a new solution for a finer granularity in order to do the least kludgy transition, and also to be compliant. i would not be against a fell-swoop approach iif existing user data had some way to migrate in advance. maybe have one minor release with the conversion means, and the next 64 bit. this has nothing to do with the filesystem, it would be for the contents of the files in the filesystem. > > it's only a matter of time before ansi reconvenes a committee for c. > > Surprise. It's under review now. > > PS: so long as a 64 bit type is atomic, it meets ANSI's requirements. good guess. this could actually force the issue. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ 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?199808190737.CAA19503>