[lkml]   [2000]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Re: Move of input drivers, some word needed from you
On Tue, Aug 22, 2000 at 11:39:30AM +0100, David Woodhouse wrote:
> 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:37    [W:0.254 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site