[Toybox] [PATCH] Add "microcom" to pending.

[Rob Landley]

[This didn't send because it prompted me if I forgot an attachment,
which I didn't, while buried behind other windows. Thank you, Thunderbird.]

Groggily replying from the Melbourne airport, which has fewer spiders in
it than I was led to believe. So far. I've been awake for over 24 hours
and I gotta catch a plane to Hobart in an hour and change...

On 01/15/2017 01:18 PM, enh wrote:
> On Sat, Jan 14, 2017 at 2:50 PM, Rob Landley <rob at landley.net> wrote:
>> On 01/14/2017 03:19 PM, enh wrote:
>>> Our device bringup folks wanted a simple serial console, both on the
>>> host and on the device. This is certainly enough to replace what I've
>>> been using personally on the host.
>>
>> I've used "netcat -f /dev/ttyS0" but you need stty to set it up and it's
>> not properly handling ctrl-C and its guts need to be moved out to
>> lib/net.c and...
> 
> i've almost implemented stty a couple of times now. the input side
> seems like a pain (though i assume that existing implementations just
> ignore the various conflicts and just do what you said in order), and
> the output side is annoyingly under-specified (what to show without
> -a, what -g should look like), and so far it's always turned out that
> i don't actually need it anyway.

It's a mess. And it's a _legacy_ mess, because nobody's actually had a
non-software tty in decades, so this (along with the $TERM variable and
termcap/terminfo/curses) is all configuration so one piece of software
to talk to another piece of software, and it doesn't matter what any of
the settings are as long as both ends agree. To which my reply is "just
pick one!" and doing that covers 99% of the modern cases.

I note that most USB serial adapters ignore your speed setting as well.
(Well, at one end. Your embedded board often has a serial port that gets
converted to USB via an onboard chip, and _that_ serial port has to
match what the USB chip thinks it's doing. But that's often a fixed rate
hardwired into the USB chip via some firmware blob, and you have exactly
one setting that _ever_ works unless you reflash that firmware.)

At the other end, if you plug a connector into a USB port on a Linux
laptop and it presents itself as a serial device, it's sending you
packets with bytes in them. All the parsing of bits to bytes was already
done at the far end by hardware that pays no attention whatsoever to
settings you apply to /dev/ttyUSB0 at this end. It's silently ignored.

Translation: _sometimes_ you need to set your tty speed when talking to
USB, but often you don't, and when you _do_ it's often to a single magic
value that's the only one supported by your USB interface, and knowing
which of the 3 cases applies to a given serial connection involves more
knowledge of the hardware than is really fair to expect.

/me cut and pastes the above into my "tofaq.txt" file. When less
jetlagged and buried by things with deadlines attached. (My linuxconf.au
talk is thursday! I'm in the "I have 350 lines of notes I need to sort
into something coherent" stage. I have Jeff Dionne's contributions, Rich
Felker's contributions, Osamu Niishi's contributions, and a lot of my
own stuff. And 45 minutes to cover it all in. Much organizing between
here and there...

>> P.S. Hmmm... in lib/ my set_terminal() isn't setting speed, my
>> tty_sigreset() is only resetting stdin not a second fd,
> 
> note that tty_sigreset (despite the name) is unrelated. that's all
> about resetting VT100-style state. the code in microcom is about
> resetting line discipline-style state.
> 
> similarly, set_terminal has curses-style interests that don't make
> sense for microcom (but are probably useful for a wider range of
> toys).

Indeed. Both things glued together into tcsetattr are mostly obsolete
though, as ranted above. :)

>> and my
>> pollinate() uses "shutdown()" so if you go:
>>
>>   echo GET / | netcat old-http-1.0-server 80
>>
>> You get output. But in _this_ case, stdin closing probably means you
>> want the program to exit because serial console doesn't do the
>> unidirectional close thing so you can't tell when/if the other end hung
>> up... Slightly Different Semantics. ALMOST the same enough to share
>> code. Hmmm...
> 
> at the same time, these functions are short enough that abstracting
> out to cover both seems like it just makes things worse.

It certainly hasn't been easy to do it cleanly. :(

> keeping the
> high-level "curses" stuff distinct from the low-level "serial line"
> stuff seems reasonable until/unless we have more of the latter, and
> even then it seems likely that the two groups would stay distinct.

You make a good point. There's stty, but I think that's fiddly enough it
can't really be abstracted out either.

If the flight back leaves in the morning instead of the evening, I might
be able to get some work done on the plane. But when the plane leaves
at/after sunset and then goes over the pacific for 12+ hours, in an
economy class where a nap just isn't happening, it's not a productive
work environment for me. (I have learned this now.)

Rob

P.S. How is spider-man _not_ an Australian superhero?