Re: EXTPROC, telnetd LINEMODE, revisited

From: Howard Chu
Date: Fri Jun 11 2010 - 07:17:46 EST

Andi Kleen wrote:
Howard Chu<hyc@xxxxxxxxx> writes:

It's been over 10 years since I looked at this last

I would suggest you repost the patch.

Looks like my email got posted twice already (oops). The updated patch was attached each time, you didn't get it?

From a quick look it looks straight forward enough.

The patch I posted still isn't quite right; it lets all of the input fall thru the regular tty input code. If ICANON is set then the tty driver will parse and act on any control characters in the input, but since the input was already fully processed on the client, any control characters remaining in the input should just be passed through literally. That should be an easy thing to fix though.

Despite the fact that most people today have ready access to high
speed broadband networking today, I think the motivation for local
character processing is as great now as it was 10 years ago. I
regularly use an ssh client on an Android phone to keep tabs on my
servers when I'm away from my home base, and sometimes cellphone
connectivity can be extremely lossy, networks can be heavily
congested, etc... Waiting for character-at-a-time packet turnarounds
in these conditions can be pretty aggravating. Also, if you're

I agree that it would be sometimes useful, I also had these

unfortunate enough to need to get access to a machine while you're
roaming away from your home network, the per-byte roaming fees can be
murder. Both of these pain points can be minimized by using local
character processing and only sending complete lines to the remote

I have some doubts this really needs to be implemented in the kernel.
Back in the old days it was important to save round trips
to user space because CPUs were so slow, but these days I don't think
that's an issue anymore for mere typing.

Couldn't you implement it in screen or a similar pty based tool?

From how I see it at the moment, everything still depends on the tty driver. Even if you devise some other mechanism, you still have to be able to intercept any ioctl's issued on the pty slave and Do The Right Thing with them in the daemon on the pty master. I guess, alternatively, you could set an environment variable in the child process that inherits the pty slave, that tells applications how to send commands out of band to the master, but that will require a lot more app-level coordination.

Another feature with readline is a command history buffer that can be
reviewed using Cursor Up/Down. Can/should we define this in the tty
driver too? Or perhaps rely on the client to implement its own command
buffer, and never mention this aspect on the wire protocol. Again,
given the purpose, it makes most sense to me to keep this feature on
the client side. But some coordination with the server would still be
useful. E.g., different programs can maintain their own persistent
command history files. It might be nice to have a way for the app to
signal to the client which command context to use for the current
history buffer, and keep them all separate. (Or not, I can see other
times where you'd just rather have it all as one stack.)

e.g. history management is definitely something that should not
be done in the kernel.

I definitely wasn't trying to suggest that the management occur in the kernel. Only that some mechanism for telling the client to toggle the feature on or off would be useful.

PS: if anyone knows where to send the patches for telnetd, please
email me. Looks like the upstream source hasn't been touched since

I think they're defacto maintained by the distributions.

I would submit them to one of the big distributions and let
that maintainer figure it out.

OK. Since it looks like the source code I'm working with came from Debian I'll start there, thanks.


-- Howard Chu
CTO, Symas Corp.
Director, Highland Sun
Chief Architect, OpenLDAP
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at