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/
This archive was generated by hypermail 2b29 : Wed Aug 23 2000 - 21:00:06 EST