Messages in this thread | | | From | (Alan Cox) | Subject | Re: Ideas for abstracting driver IO from bus implementation? | Date | Wed, 17 Mar 1999 05:01:38 +0000 (GMT) |
| |
> My thought is to have a socket driver publish a set of entry points > for primitive IO operations: effectively, replacements for readw, > writew, inb, outb, and friends. These would be passed out to any
Ok so you replace a 1 clock pairable operation with 3 or 4 memory operations a call, and a pipeline stall.
That tells me its not general purpose 8)
> read_io_byte(sock_handle, port) (or sock_handle->read_io_byte(port), > or io_handle->read_byte(port)), and having a header file that could > collapse this to inb() based on a configuration option.
I guess "sock_handle" becomes bus.
> retooled to support indirect device accesses. I guess the 8390 driver > has already had something like this hacked in for a special case, so > there's some precedent for it. Any comments?
if you look at the 8390 you'll see it doesn't take any jumps, it turns a direct lookup into an indirect with scaling. So it tends to cost 1 or 2 clocks at most. It also comes out as null on any platform that isnt sick like the mac and amiga.
To give you an example why this matters in many cases - my I2O code paths are (last time I checked the asm)
2 instructions to get a simple message 14 instructions to build a typical message 1 instruction to post it
So it takes me 17 clocks to tell the controller to do something. If you wrapped the read/write's it would probably double it
Macros I would guess are the right answer if you can encode a bus/port pair into 32bits. Then you can rebuild any driver with
DFOR_PCMCIA --include pcmcia_strange.h
Alan
Alan
- 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/
| |