Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [PATCH 00/12] kmap_atomic cleanup for 3.6 | Date | Mon, 25 Jun 2012 15:18:08 +0000 |
| |
On Monday 25 June 2012, Cong Wang wrote: > On Sat, 2012-06-23 at 21:11 +0000, Arnd Bergmann wrote: > > On Saturday 23 June 2012, Cong Wang wrote: > > > After few releases, it seems there are no more callers > > > using the deprecated form of kmap_atomic(), the one > > > with two parameters. So we can remove it now and remove > > > the KM_* definition except KM_TYPE_NR together. > > > > > > All the patches are available at: > > > > > > git://github.com/congwang/linux.git #kmap_atomic > > > > > > > What is the significance of having an architecture-specific > > definition for KM_TYPE_NR now? Should that be replaced > > with a fixed value in include/linux/highmem.h so we can > > remove the asm/kmap_types.h files entirely? > > > > Different arch has different values for KM_TYPE_NR, I am not sure if > unifying them to a fixed value could fit all?
Well, that's something you could find out in the review.
> 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.
The only architecture that actually seems to have a restriction here is tile, which defines it to 8.
I would suggest putting that value into include/linux/highmem.h, it seems more than sufficient. I would structure the series to have your patches 1 and 9 through 12 first, then remove all explicit #include <asm/kmap_types.h> statements (you have proven that they are not required already) and finally add the define in linux/highmem.h and remove the arch specific headers.
Arnd
| |