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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:21 EST