lkml.org 
[lkml]   [2000]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Re: Move of input drivers, some word needed from you
[incredible cc-list trimmed]

> We need an architecture similar to the net devices.

agree

> The tty layer needs to set termios, and write characters. tty layer
> should copy these into the circular buffer without leaving that to the
> individual driver. (*) Usually the interrupt routine will just empty
> the circular buffer.

I'd agree that the arch is very similar to net devices (network devices
are in fact nothing else than a very specific form of serial devices :).

BUT, by the same argument, the ol' circular buffer thingy needs to go as
well.

Example - our embedded CPU has full DMA to every I/O and the serial port
can easily do 1.8 megabaud and has a 6 megabaud mode as well. Trying to
get that to work with serial.c was a minor headache. Just because the PC
still has shit-for-serial-ports should not be a limitation to scalability.

My solution was to let the driver DMA directly into the tty flipbuf while
the sends still has to be copied into a buffer.

SOmething similar to the skb's would be preferable - so I can just take
write blocks and chain them into the DMA hardware. Incoming data can go
into "skb's" as well up to the tty.

My point is just that if we're going to go through the horror of
completely redesigning serial.c we might as well get rid of the "char by
char" mentality, at least not so that it limits the _fast_ ports out
there.

> Now, currently, most of the recieve handling is postponed to the
> bottom half. I question the usefulness of this optimization. It
> certainly adds latency. What is it that needs to be done on reception
> of a few chars? Copy the data to userspace, and hit the waitq of the
> process that's waiting for data. If you want to prevent the races, use
> a kernel-space circular buffer, and do the processing (copy to
> userspace) in the context of the wokenup process.

Forget the circular buffer and use a chain of buffers instead on the
incoming queue. A circular buffer is just a fixed buffer-chain of 1-byte
elements, but with an overflow headache and a flipping problem..

> It's not as if this is highly time-consuming: we already have to copy
> the data somewhere, so that part is "unavoidable". And the possibly

A line discipline doing raw tty I/O can do zero-copy, in the sense that
the serial driver on the receiving end gives away its received buffers to
the upper levels. Just like in the network stack.

> just enable tx buffer empty interrupts. On others it may have to push
> a buffer full of data onto the card (for example, sx doesn't interrupt
> for tx_empty unless the buffer was previously filled).

Just don't think all serial HW's do char-by-char or have buffers that go
empty.

-Bjorn


-
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/

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