Messages in this thread |  | | | Date | Thu, 10 Aug 2000 14:29:19 +0100 | | From | Malcolm Beattie <> | | Subject | Re: 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/
|  |