Re: [PATCH 00/12] kmap_atomic cleanup for 3.6

[Arnd Bergmann]

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