Messages in this thread | | | Date | Tue, 22 Aug 2000 13:48:23 +0200 (MET DST) | From | Bjorn Wesen <> | Subject | Re: [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/
| |