Date: Mon, 29 Oct 2001 12:45:52 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: tlambert2@mindspring.com, Peter Wemm <peter@wemm.org> Cc: arch@FreeBSD.ORG Subject: Re: calm, orderly, deliberate time_t transition.. Message-ID: <p05101000b80340e7a072@[128.113.24.47]> In-Reply-To: <3BDD8CBF.80D85ED4@mindspring.com> References: <20011029064257.ACB573808@overcee.netplex.com.au> <3BDD8CBF.80D85ED4@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 9:07 AM -0800 10/29/01, Terry Lambert wrote: >Peter Wemm wrote: >> 2: new platforms should start at time_t 64 bit >> > > 3: Once we've tested the water on the new platforms, *then* > > progress towards activating it on alpha and then x86. > >The problem with this is that it pushes both the onus and all >the experience off onto the new platform people. > >FreeBSD already has a considerable x86 bias that any attempt >at a new platform has to overcome, just to boot. Putting >what amount to gratuitous changes in the path of them is just >that much more barrier to entry. Speaking for my own situation, I already own PowerPC systems and I have no qualms about buying more. I'll be happy to run FreeBSD for PowerPC just as soon as the "basic operating system" level is working (I don't work at the kernel level, so I'd want something booting into multi-user and reasonably stable at the kernel/device-driver layers). I want 64-bit time_t's, and I don't see that issue as any barrier to my running FreeBSD/ppc. We have to start somewhere, and in my mind it makes good sense to start on platforms which we KNOW are not currently running any "in production" services. If we don't move i386 and Alpha to 64-bit time_t's in 5.0, then we can still think about doing it for 6.0. This would mean the "new platforms" are running 64-bit as 5.0-stable at the same time that i386 and alpha are running it as 6.0-current. So, any bugs come up for 64-bit time_t's on i386 will be seen in the current branch at the same time the "new platform people" might be seeing similar problems in their stable branch. I am sure we can find *some* problem with any suggested course of action. This course of action is not perfect either, but I think it's reasonable. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05101000b80340e7a072>