You can't spell "evil" without "vi".

Denys Vlasenko vda.linux at googlemail.com
Sun Oct 19 18:59:55 UTC 2008


On Sunday 19 October 2008 06:22:37 am Rob Landley wrote:
> Heh, ok, now I found the message.  (Just because I'm paying attention to the 
> busybox list again doesn't mean I've got my mail filters set up right yet. :)
> 
> > But scheduling in the sender can.
> 
> The sender almost certainly is using something like a 16550a UART, which has a 
> 16 byte output buffer.  (In addition the kernel may insert a pipe buffer on 
> the output side.)
> 
> If your escape sequences are written to the char device as single blocks,

This case is ok. Bad case is:

while (1) {
	n = read(fd1, buf, 1000);
	if (n <= 0) exit(0);
	write(fd2, buf, n);
}

if fd1 is a serial line, we easily would read ESC sequence byte-by-byte.
If fd2 is a network, we will feed it byte-by-byte to network.
Since read() usually blocks, it can be delayed for *seconds*
if there is enough load on the system.

> the  
> main reason for your kernel to block the sending process is because the 
> output buffer filled up.  (Other reasons to block shouldn't decouple the 
> sequences, either it blocks before sending or you're in the kernel and the 
> whole sequence gets queued atomically.)  This means you have at least 16 
> chars worth of transmission time for the sending process to get scheduled 
> back, and here slower rates _help_ you; at 1200 bps that's 100ms.
> 
> > If sender is not a hardware 
> > but a process (say, sitting on the other side of ssh) and it
> > takes input from, say, serial line, it may read only one char, ESC,
> > and send it to us over ssh. Then it will read more and send more to us.
> > Delay between ESC and the rest here is affected by how *that process*
> > is scheduled, and there scheduling delays can not be predicted.
> 
> A) Your example seems fairly contrived; ssh by itself can't do that, and ssh 
> going _into_ a serial line can't do it either (it gets the 16 byte buffer).  
> You need _two_ levels of reblocking for the case you're talking about to even 
> come up.

How about "ssh from serial to network"?

Log in to your router over serial line and then ssh from it somewhere.

> B) The http://en.wikipedia.org/wiki/Nagle_algorithm is the default on Linux, 
> and its _job_ is to re-coalesce exactly this sort of thing. :)

ssh turns it off for interactivity reasons.
--
vda



More information about the busybox mailing list