Messages in this thread | | | From | David Woodhouse <> | Subject | Re: [PATCH] Re: Move of input drivers, some word needed from you | Date | Tue, 22 Aug 2000 11:39:30 +0100 |
| |
torvalds@transmeta.com said: > A lot of serial.c is actually completely hardware-independent, and > serial.c in many ways is already "two drivers", in that it both knows > how to handle the low-level hardware AND it knows how to handle the > higher-level issues. And I don't think it would be bad to split it up > some more.
The problem is that if you start to decouple the chipset driver from the code which knows how to access the chip, you end up with lots of horrible indirect function calls in the inner loops. This isn't really going to help improve performance - and the serial driver has one of the biggest problems w.r.t latency already.
I figure I can get away with it for the MTD code (see the interaction between the CFI chipset code and the 'map' modules) because flash is generally slow as hell anyway, but for serial it's just not that feasible.
We have the same problem when readb() becomes something other than a #define or inline function.
One possibility for serial might be to reuse the generic chipset code in source form rather than object form - i.e. define serial_readb() et al. functions for your particular board/bus/mapping and then #include <generic_16550.c>. That's quite ugly though.
-- dwmw2
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |