[lkml]   [2000]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ioremap return type
Jamie Lokier writes:
> David S. Miller wrote:
> > 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.
> >
> > 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?
> >
> > This is why the typedefs are necessary to solve the problem properly.
> Unfortunately a typedef alone won't even issue a warning for code which
> uses the "sane type" directly.
> IMO nice would be a really opaque cookie, s.t. readl is passed the
> cookie _and_ offset. That also leaves the way open for lots of
> different implementation methods for readl et al., including debugging
> checks, range and I/O tracing. (E.g. I've seen drivers access ports
> outside their allocated range, due to typos).

Why not make the types opaque in the same way as ptes:

typedef struct { unsigned long addr; } ioaddr_t;
#define readl(ioaddr) __readl(ioaddr.addr)
void *ioremap(ioaddr) {
unsigned long addr = ioaddr.addr;
inline iooffset(ioaddr_t ioaddr, long delta) {
ioaddr.addr += delta;
return ioaddr;
Assuming gcc can generate the same code and doesn't get confused
by any of the struct passing and manipulation.


Malcolm Beattie <>
Unix Systems Programmer
Oxford University Computing Services

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:58    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean