[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200812031313.57754.arnd@arndb.de>
Date: Wed, 3 Dec 2008 13:13:57 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Andi Kleen <andi@...stfloor.org>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Clean up namespace in kmap_types.h
On Wednesday 03 December 2008, Andi Kleen wrote:
> > The patch looks ok, but it seems wrong to do this only on one architecture,
> > because kmap_types.h is mostly identical across all architectures.
> >
> > I'm working on patches to consolidate a lot of generic headers, why not
> > add this in a generic way and make x86 use that version?
>
> I was hoping that it could be still fixed for 2.6.28. Perhaps
> that would be too intrusive that late? That is why I hope
> it can be still considered even if it's x86 only.
I don't think it's too intrusive, it just doesn't fit the 'strictly
bug fixes' definition.
> For .29 I suspect in fact the best way would be to just move it into linux
> and use a superset because I don't think it's a big problem to waste 3-4
> pages of virtual space for this.
Yes, that would work as well. FWIW, we currently have the following
nonstandard kmap types:
avr32: KM_PTE2 (unused)
frv: __KM_CACHE, __KM_PGD, __KM_ITLB_PTD, __KM_DTLB_PTD (unused
except for __KM_CACHE)
powerpc: KM_PPC_SYNC_PAGE, KM_PPC_SYNC_ICACHE
It should be fair to introduce common types KM_DCACHE (__KM_CACHE
and KM_PPC_SYNC_PAGE) and KM_ICACHE (KM_PPC_SYNC_ICACHE) for these.
> > --- /dev/null
> > +++ b/include/asm-generic/kmap_types.h
> > @@ -0,0 +1,29 @@
> > +#ifndef __ASM_GENERIC_KMAP_TYPES_H
> > +#define __ASM_GENERIC_KMAP_TYPES_H
>
> So are you submitting this?
It's part of a larger series that I'm planning to submit for 2.6.29,
but I wouldn't mind if you take care of this file independently.
Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists