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).
Many drivers use a struct to define the offsets in their I/O or iomem
space. E.g. acenic.c: readl(®s->CpuCtrl). We know that's not
portable in the sense that struct layout is not guaranteed. However,
provided all the fields are suitably padded & aligned, it works in
practice. (So far..)
Those drivers will compile with the simplest void * -> unsigned long
change, but it will be lots of work to get rid of all the warnings.
-- Jamie
-
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