Re: ioremap return type

[Philipp Rumpf]

On Thu, Aug 10, 2000 at 07:44:30AM +0200, Abramo Bagnara wrote:
> Philipp Rumpf wrote:
> > constant offset to the address, ideally, it shouldn't hurt performance very
> > much.
> 
> ... but the problem is that it makes the debug harder and empiric (i.e.
> you'll see the bad effect only and if that specific code path is
> triggered) instead of static and easy (i.e. done at compile time
> following the warning track).

You won't see the warning, usually.  Most drivers cast ioremap's return value
directly, so it doesn't matter to them.

> > I don't see why any of this should happen before 2.5 though.
> ... because this is a debug strategy?

It's also an API change.  Worse, it's an API change that's not entirely
compatible with the compatmac.h approach - some architectures #define
ioremap.

Most importantly, there seem to be several other things we might want to
change in the PCI MMIO API: two-argument read*, three-argument write*,
{8,16,32,64} rather than [bwlq], possibly a pci_dev-oriented ioremap,
possibly use some form of ioremap for PIO as well.

Let's not end up with three different APIs in 2.2, 2.4, and 2.5.

Back to the original subject, I still believe it is much more efficient to
make broken code fail at runtime than hope we'll find it because it didn't
use a cast.  It can be made to fail reliably - at the cost of wasting twice
the virtual memory for vmallocs.  The actual overhead at runtime should be
irrelevant.

	Philipp Rumpf