> But! Yeah here it comes, I do think it would be a good idea to add an
> extra parameter to vremap() which specifies the cache-mode that is
> supposed to be used for the mapping. We do need this for the m68k and
> so we currently use our own kernel_map() rather than vremap(), and I
> think some other architectures might need it as well.
Agree. Furthermore broken PPro Bioses who forget to set up correctly MTRR
do exist. I had the proof last night after a few mail exchanges with
Patrick St. Jean <psj@cgmlarson.com>. He had to switch to v2.1 and use
ioremap_nocache.
Pentia are much more reliable in this respect since cache disabling is
done by chipset hardware as a function of the physical address.
> I would like to have a function with the same name for all archs so
> one wont have to dig half way through the kernel to figure out what is
> going on in some other driver when you want to clone it. Architectures
> which do not need this can just ignore the extra parameter, but maybe
> this really indicates that vremap() is really an architecture specific
> thing and should be moved to arch/foo/mm/?
Same function for all architectures with one additional parameter is best
IMO. Mapping devices in kernel space is a quite generic need and should
not be architecture specific. Anyway the architecture dependance can
be hidden in #include <linux/mm.h> to try to avoid #ifdef's in drivers.
>
> Jes
>
> PS: Besides vremap() is really one of those functions where you cannot
> figure out from its name what it is actually doing, so maybe a
> renaming was a good idea as well.
>
Done in V2.1, it's called ioremap and has the additional ioremap_nocache
version to explicitly disable caching.
Gabriel