* john stultz <[email protected]> wrote:
> > - I still don't like the idea of a generic gettimeofday() as it prevents
> > more optimized versions, e.g. on the one end with a 1MHz clock you only
> > have usec resolution anyway and this allows to keep almost everything
> > within 32bits. On the other end 64bit archs can avoid the "if (nsec >
> > NSEC_PER_SEC)" by doing something like ppc64 does, but requires a
> > different scaling of the values (to sec instead of nsec).
>
> Fair enough. I agree arches should be able to have their own arch
> specific implementations. If you really have to micro-optimize
> everything, just don't enable CONFIG_GENERIC_TIME and have your own
> timekeeping subsystem!
>
> But at the same time, I don't like the idea of needlessly having 26
> different versions of gettimeofday that do exactly the same thing
> modulo a few bugs. :)
I like the first 9 patches, but regarding 10/10 i very much agree with
John: it moves us to per-arch gettimeofday again, which is a big step
backwards and reverts some of the biggest advantage of John's
clocksource patchset!
Also, lets face it: with the union ktime_t type most of the '64-bit is
slow on 32-bit' issues are much less of a problem. If some 32-bit arch
wants to pull off its own timekeeping system, it can do so - but
otherwise we want to move towards generic, unified (as far as it makes
sense) and generally 64-bit-optimized subsystems. In 1995 i'd have
agreed with Roman, but not in 2005.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
