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

[Dominik Brodowski]

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