Messages in this thread | | | Subject | Re: [PATCH 00/12] kmap_atomic cleanup for 3.6 | From | Peter Zijlstra <> | Date | Tue, 26 Jun 2012 10:17:35 +0200 |
| |
On Mon, 2012-06-25 at 20:43 +0000, Arnd Bergmann wrote: > On Monday 25 June 2012, Peter Zijlstra wrote: > > > > On Mon, 2012-06-25 at 15:18 +0000, Arnd Bergmann wrote: > > > > Different arch has different values for KM_TYPE_NR, I am not sure if > > > > unifying them to a fixed value could fit all? > > > > No you can't. Some arch's have arch specific KM_TYPE thingies, like FRV. > > Ah, right. Is it only FRV or are there any others?
FRV is the only one I can remember, but like always, just check all archs.
> > > > For safety, I kept their original values. > > > > > > My fear is that it will make it harder to clean that code up for > > > real, when there is no longer an indication about where the number > > > comes from. > > > > Agreed, I'd much prefer it if we'd come up with a sane way to compute > > the max value before doing away with these enums. > > > > Sadly I haven't been able to come up with a sane way short of whole > > program analysis. > > How about putting that constant into asm/highmem.h then, and adding a > default like > > #ifndef KM_TYPE_NR > #define KM_TYPE_NR 8 > #endif > > in linux/highmem.h? Then FRV and anything else that needs it can override > the value and the other ones don't need to bother.
At least put in a hand-wavy argument supporting whatever one number that's being put in. That way a reader at least as some incling as to where it comes from and what needs checking if it turns out its wrong.
| |