Messages in this thread | | | Date | Thu, 10 Aug 2000 15:14:17 +0100 | From | Philipp Rumpf <> | Subject | Re: ioremap return type |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |