Messages in this thread | | | From | (Alan Cox) | Subject | Re: Ideas for abstracting driver IO from bus implementation? | Date | Thu, 18 Mar 1999 00:29:13 +0000 (GMT) |
| |
> like I2O. I see it being used mainly in unusual situations where > specific hardware constraints (independent of performance) make it > impossible to use the native bus abstractions for certain devices.
Yes. Thats where it makes sense, and why macros probably make good sense.
> general coding scheme for putting the bus info in the address seems > tricky to me. I guess I can just pretend that the device is mapped > into the normal IO space (and allocate a range of addresses as if it > is, as a placeholder), but then the macro for inb() would need to > reverse the mapping, which would be messy.
The m68k people do that for a couple of things. A macro solution where you end up with
bus_inb(my_bus, 0x380);
is fine since after cpp on most things its now an inline inb() and my_bus has evaporated
- 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/
| |