>>> 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...)
> Keep in mind that 40 years ago we were just entering the "Second
> Generation Computers (1956-1963)"
> (http://www.digitalcentury.com/encyclo/update/comp_hd.html)
> which started out with the transistor. 40 years is a long time.
> 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.
Perhaps there's a way round it that fixes the problem without
sacrificing performance...
1. Split the kernel time counter into TWO values.
2. The first value is a long long value that specifies the kernel
boot time in seconds since origin. Since this value is only set
once per kernel boot, performance is not an issue.
3. The second is a long that specifies how many seconds since the
kernel last set the first value.
This changes the definition of the associated Y2K-type problem, and
the problem would then exist ONLY for a 32-bit system whose uptime is
rather more than 68 years.
> 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?)...
ELKS is basically a Linux port that runs on XT's, never mind 286's,
and development is still going ahead.
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
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/