On Tue, Aug 22, 2000 at 11:39:30AM +0100, David Woodhouse wrote:
>
> 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
indirect function calls aren't that expensive anymore. especially when you
consider CPUs at 500 MHz and PCI still running at 33 MHz, a few cycles for
an indirect call aren't all that terrible.
> improve performance - and the serial driver has one of the biggest problems
> w.r.t latency already.
The serial driver suffers from other drivers leaving interrupts disabled for
too long. Making the calls indirect wouldn't be a problem (except on old
386-class machines, that is).
> We have the same problem when readb() becomes something other than a
> #define or inline function.
It is in generic alpha kernels.
> 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.
yuck.
Philipp
-
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