The problem is using a 64-bit time_t on a 32-bit system, especially on an
embedded one where performance per $ counts... long longs are SLOW, and
for such a commonly used value it would be a significant performance hit.
Sure, it would be nice, but so would a 128-bit value. That would solve
time problems for quite a while, but it's just not practical. That's why
Sun went the way of fixing it for 64-bit machines and letting the 32-bit
machines fall to the wayside.
Oh. And keep in mind that linux won't even run on a 16-bit machine
(although there was a port to the 286 at one point?)... :-)
-Rob
On Tue, 1 Jun 1999, Ard van Breemen wrote:
> Date: Tue, 1 Jun 1999 07:39:40 +0200 (CEST)
> From: Ard van Breemen <ard@cstmel.nl.eu.org>
> To: linux-kernel@vger.rutgers.edu
> Subject: Re: Migrating to larger numbers
>
> On Mon, 31 May 1999 hagopiar@vuser.vu.union.edu wrote:
> > But there might be a way to compromise: Would it be possible to make
> > uid_t/gid_t implementation specific? As I read it, __kernel_time_t is an
> > unsigned long. If my memory serves (which is growing less and less likely
> > these days), this means that it is a 64-bit value on 64-bit architectures
> > and a 32-bit value on 32-bit architectures. This is the route that Sun
> > took with their 64-bit architectures with time_t, based on the (IMO
> > perfectly valid) assumption that in 38 years 32-bit binaries will be done
> > with.
> This is not a valid assumption, and there is 1 good example for that:
> Y2K...
> The idea that 32 bit will be obsolete is probably non-true. We are still
> using 4 and 8 bit microcontrollers. By then a lot of 32 bit
> microcontrollers will be common in regular appliances. Those appliances
> will by then be more complex, and therefore need a base that already has
> no time problems.
> I can see the logica with the amount of users on a 32 bit system, but not
> with the time. 38 years is not that long, and I know that there still will
> be a lot of 32 bit controllers out there (and even 8 and 4 bit...)
>
>
> --
> intel1: 7:29am up 26 days, 7:17, 10 users, load average: 0.00, 0.00, 0.00
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/