Re: ioremap return type

[Philipp Rumpf]

On Wed, Aug 09, 2000 at 06:27:03PM -0700, David S. Miller wrote:
>    From: Jes Sorensen <[e-mail]>
>    Date: 	09 Aug 2000 19:54:05 +0200
> 
>    Jamie> Name it ioaddr_t -- to clarify usage for _new_ driver authors.
> 
>    Please don't, we have way too many silly typedef's already that are
>    just hiding sane types underneath.
> 
> The whole point is we don't want driver authors to have any idea
> what type it is.  What we want them to know is:
> 
> 1) It is returned from ioremap()
> 2) It can be passed to iounmap()
> 3) It can be passed to {read,write,in,out}{b,w,l}() with an optional
>    byte offset added to it.

Since when can it be passed to out[bwl]

> Otherwise, the thing is to be completely opaque.  If you expose the
> "sane type" underneath, driver developers will never get this right.
> 
> You can document the three points I made above in 100 different
> places, driver authors are still going to get it wrong unless you make
> it such that their driver does not compile unless they follow the
> rules above.  See?

I actually believe just making buggy drivers not work will be sufficient.
Even if it wasn't changing the type from void * to unsigned long won't
make any code miscompile.

> This is why the typedefs are necessary to solve the problem properly.

Have we actually tried breaking things for the simple dereference case ?

> Sure, the programmer can use really ugly casts to subvert the compile
> failure, but that will stick out and be an eyesore to anyone who looks
> at the code.  Currently it's just too easy to convert the void * from
> ioremap into any pointer type whatsoever without casts etc. and this
> is why so many people get it wrong.

Maybe it's also that it's easy to convert the void * and their code
actually works (which it shouldn't).  Even simply adding or subtracting 1
from the ioremap return value should catch the problem - strange effects
on i386, unaligned traps and even stranger effects on most risc
architectures.

	Philipp Rumpf