Messages in this thread |  | | Date | Thu, 22 Aug 2002 18:51:08 +0200 | From | Dominik Brodowski <> | Subject | Re: [PATCH]: fix 32bits integer overflow in loops_per_jiffy calculation |
| |
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/
|  |