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
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

--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [from the cache]
©2003-2011 Jasper Spaans