lkml.org 
[lkml]   [2000]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.239 / U:0.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site