Prev: [PATCH 1/3] mfd: add STMPE811 core support
Next: AT91: add new at91 chips in at91sam9g45 family
From: Howard Chu on 11 Jun 2010 06:30
It's been over 10 years since I looked at this last

http://lkml.indiana.edu/hypermail/linux/kernel/9911.3/0650.html

and apparently no one else has been interested since then. A random
conversation got me looking into it again, and now I have it working. However,
obviously the world has moved on from telnet to ssh, and my goal in posting
now is to hash out what needs to be done in the kernel so that LINEMODE can be
fully supported in ssh.

First you'll note that this patch is fairly similar to the one I posted back
in 1999. The bug I was chasing down back then turned out to be in the telnetd
source, not in the tty driver, so this patch has only needed minor refreshing
to bring it up to date.

There are some other issues that need to be addressed though to make this
feature maximally useful today:

GNU readline and other similar code is prevalent today, and uses many
additional editing characters that aren't represented in termios. The telnet
Linemode spec in RFC 1184 accomodates most of these characters but without
termios support there's no way to communicate these settings between telnetd
and the readline library (or whatever other app). Most of the editing features
provided by readline really belong on the local client anyway.

Linemode assumes single-character codes for input functions, but on common
terminals (e.g. ANSI/VT100 style) a lot of navigation keys send
multi-character sequences (cursor movement, etc.).

So I'm looking for suggestions on ways to approach this, that will allow as
much functionality as possible to be handled by a local client.

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 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 server.

The telnet Linemode spec serves as a pretty good starting point for adapting
to ssh, but these details still need to be addressed - can/should we add
additional command characters to the tty driver? The telnet spec defines these
commands that the tty driver is missing:
Move cursor one character left, right
Move cursor one word left, right
Move cursor to beginning/end of line
Enter insert/overstrike mode
Erase character to the right
Erase word to the right
Erase to beginning/end of line

Also it would be nice to be able to define other forwarding characters, which
don't necessarily have an edit function. E.g., <TAB> for word completion.

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.)

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

ftp://ftp.uk.linux.org/pub/linux/Networking/netkit/

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
From: Andi Kleen on 11 Jun 2010 06:50
Howard Chu <hyc(a)symas.com> writes:

> It's been over 10 years since I looked at this last
>
> http://lkml.indiana.edu/hypermail/linux/kernel/9911.3/0650.html

I would suggest you repost the patch.

From a quick look it looks straight forward enough.

> 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
problems.

> 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
> server.

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?

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

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

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.

-Andi
--
ak(a)linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Howard Chu on 11 Jun 2010 07:20
Andi Kleen wrote:
> Howard Chu<hyc(a)symas.com> writes:
>
>> It's been over 10 years since I looked at this last
>>
>> http://lkml.indiana.edu/hypermail/linux/kernel/9911.3/0650.html
>
> 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
> problems.
>
>> 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
>> server.
>
> 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
>> 2000.
>
> 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.

> -Andi

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Howard Chu on 11 Jun 2010 16:30
Howard Chu wrote:
> Andi Kleen wrote:
>> e.g. history management is definitely something that should not
>> be done in the kernel.

I must be going senile or something. You're absolutely right of course. I just
dug up my old telnet patches from 1989 that implemented the command history in
the client. All that we need today is a patch for GNU readline that makes it
mostly do nothing when EXTPROC mode is set on the tty.

We still need to be able to forward on <TAB> of course. We can define
additional forwarding characters using VEOL or VEOL2, but I think they also
have the semantic of terminating the input line, which is not what we want
here. Since they are so rarely used for their original purpose, would it be a
terrible thing to subvert them to this purpose, or can we just add a new VFWD
character to the tty driver?

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

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH 1/3] mfd: add STMPE811 core support
Next: AT91: add new at91 chips in at91sam9g45 family