[TUHS] Stdin Redirect in Cu History/Alternatives?

[Dan Cross]

On Sun, Dec 11, 2022 at 9:28 AM Steve Nickolas <usotsuki at buric.co> wrote:
> On Sun, 11 Dec 2022, Michael Kjörling wrote:
> > On 10 Dec 2022 19:22 -0500, from clemc at ccc.com (Clem Cole):
> >> My memory is there were also a bunch of two
> >> letter programs, rx/sx and rz/sz and the like.  Frankly its been so long
> >> since I had any use for them, I've forgotten.
> >
> > I remember at least sz/rz from my early (for me) forays into UNIX,
> > back when ZModem was pretty much state of the art at least on micros
> > and I had files locally that I wanted remotely or vice versa. The
> > mnenomic being s(end)/r(eceive) z(modem); "send" and "receive", of
> > course, being local to the remote host, so the opposite sense of what
> > one would do with the terminal emulator program that one interacted
> > with locally. So "sz <some file>" at the prompt, then activate the
> > "receive ZModem transfer" function locally; or "rz <some file>", then
> > activate the "send using ZModem" function locally.
> >
> > I think the host I was on at the time (which appears to have been some
> > Solaris) also offered XModem and YModem variants as [rs][xy], but I
> > never used those because someone had at some point told me that ZModem
> > was better. :-)
>
> Kind-of a pain to type as I'm SSHing in from my phone, but they still
> exist and I have "lrzsz" installed on my Debian box.

And as I mentioned earlier, they're still very much used.

I recently wrote the initial bootstrap program that runs when the x86
cores on our machine come out of reset
(https://github.com/oxidecomputer/phbl/). However, that's for
production use; for internal engineering use we have _another_ tool,
also written in Rust, that is an interactive standalone program. This
lets us do things like poke at physical memory, read/write MSRs, and
all of that fun stuff, before loading an operating system. So how does
one load the OS? Our machine has a part that includes a 3
MBAUD-capable UART, and we use xmodem to transfer the kernel (and a
ramdisk image!) over that, where the engineering tool can load and
jump into it. The standalone program implements xmodem internally,
whereas we use `sx` on the dev host side. Basically, there is a
built-in commands to perform the transfer, another that effectively
says "there's an ELF image in physical memory $here: load it and
return the entry point" and finally another command that can jump to
an arbitrary virtual address (yes, we load the host OS in 64-bit mode
and treat the kernel like any old "normal" ELF binary).

As the ramdisk image has grown (more and more debugging tools are
included as we move ever forward in the bringup and development
process), latency here is annoying. I added support for compressed
kernel and ramdisk images, which gave a 2.5x speedup (directly
proportional to the usual compression ratio we see on these images)
which ameliorated but did not eliminate the pain. We briefly tossed
around the idea of implementing zmodem, but decided it wasn't worth
it. We _could_, in theory, make use of the enhanced kermit with
sliding windows and so on, but again decided it wasn't worth the
effort for an engineering tool.

Incidentally, my colleague Matt Keeter ran into performance and
reliability issues with xmodem over the USB serial driver in macOS,
and wrote a small shim that side-stepped the host OS device. He did a
nice write-up of it here:
https://www.mattkeeter.com/blog/2022-05-31-xmodem/

I think this is in line with Larry's question about non-legacy
use-cases for these ancient serial transfer protocols in late 2022.

        - Dan C.