Re: [PATCH]: fix 32bits integer overflow in loops_per_jiffy calculation

Dominik Brodowski (devel@brodo.de)
Thu, 22 Aug 2002 18:51:08 +0200


Hi,

> > Well... it's clearly located inside kernel/cpufreq.c, so there is
> > little risk, though it may be worth a big bold comment
>
> Hmm, in my experience people hardly ever read detailed comments even
> when they are well-written. Perhaps if you called the function
> imprecise_scale or coarse_scale, it might ring a bell.

First of all, it's located in include/linux/cpufreq.h [to be accessible for
arch/i386/kernel/time.c, called cpufreq_scale() which should mean that it is
only meant for CPUFreq and nothing else.

> >>In this case a generic scaling function, while not a standard libgcc/C
> >>library feature has potentially more applications than this simple
> >>cpufreq approximation. But I don't see very much the need for scaling a
> >>long (64 bit on 64 bit archs) value, 32 bit would be sufficient.
> >
> >
> > Well... if you can write one, go on then ;) In my case, I'm happy
> > with Yoann implementation for cpufreq right now. Though I agree that
> > could ultimately be moved to arch code.
>
> Ok, I'll give it a try this week-end (PPC, i386 and all 64 bit should
> archs should be trivial).

IMHO per-arch functions are really not needed. The only architectures which
have CPUFreq drivers by now are ARM and i386. This will change, hopefully;
IMHO it should be enough to include some basic limit checking in
cpufreq_scale().

Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/