From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29357 invoked from network); 11 Dec 2022 15:06:44 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 11 Dec 2022 15:06:44 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 400B3423F7; Mon, 12 Dec 2022 01:06:38 +1000 (AEST) Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by minnie.tuhs.org (Postfix) with ESMTPS id EE251423E6 for ; Mon, 12 Dec 2022 01:06:32 +1000 (AEST) Received: by mail-lj1-f169.google.com with SMTP id z4so9948415ljq.6 for ; Sun, 11 Dec 2022 07:06:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=46H5q5pJFgteY7PM+n69F/k5Qv5VhNoiyudmSv4zcbg=; b=F0r71uZlbisPxjVldbTma3nexKXgjgDmB9CKy1Tf4lcLtcQocUeDBNLpGCFrgC8m9H IkTjlRZ1malSLbveV+jQOgAiMmPt9pWwydP7rB7og7uNf5riId5mx4wzFrjT7VW6/+75 cbolbUIAXKy5149B5mCIXkQhf2le88gmGKZJM/n14GkClwJPGV7bAFWWEJotsgyUz1Ud dx7mFkm40OzL+mU+TSCKdyDHkCVDBWG9olUTWohwC37aQ3PhMSlii7GbHMvAiIKlxtEZ x6+zB7aCp/DCDbT2mSe9sy+AdNrZ0212jPHI6y3aSYp2WUIuFtURxBCOce3lxzhEVww+ 6s0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=46H5q5pJFgteY7PM+n69F/k5Qv5VhNoiyudmSv4zcbg=; b=AUXM7IpKAfNGN4F+QyrGX6y/wkRVklcm2h4gToqJatGqQlmWEvpCG4OSFbqDa/fUhO /+BqrWw6ZuEA9sbDSA9cnqGg2Ov/fYzsQ/LU1thAmwTkC/N0sS1t05SsAsthXX7VxWAc YDkHVKht/Akl5sKqlezYBXKGrBQKk8wAOWl0pXwSN7bQWA/fSAAKkwfcggrPXzqxaEtY w303yUmGkGQXW30Qot+wkHMr2x63mlWbmx33YrO9UWaCigCU74vY2dpzq+tOzBiZ73IY vK/jq2YLTSiWnQHZQx2iFXB2i8fc+io/wVreKbtDOVYPw7e+rAEqWjjBmiGfAZ1RpuZf z9mw== X-Gm-Message-State: ANoB5pmu361G97A7z0vUB/vcLVIhjuwOM122FJgGxHExiROlh0R3yQHr 214keAEYqkCLN/Ld33B2x66ugBI0xxTlZJZ5Uu/wU8y458g= X-Google-Smtp-Source: AA0mqf5UAs9UfpbRnQvSC0Mtay2XaaEhpCoQynep2opAUsBKq/vut7w9sK554XJDR9Z8dZqLqwOLryxPMp7qvxb0ngk= X-Received: by 2002:a2e:bd85:0:b0:279:7ee8:d06e with SMTP id o5-20020a2ebd85000000b002797ee8d06emr22398011ljq.215.1670771130902; Sun, 11 Dec 2022 07:05:30 -0800 (PST) MIME-Version: 1.0 References: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> <3161f965-99d2-4f7a-aa35-a30837ae8e37@home.arpa> In-Reply-To: From: Dan Cross Date: Sun, 11 Dec 2022 10:04:54 -0500 Message-ID: To: Steve Nickolas Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: QBJY7LUUADHIXZYNUQ3CHI6FA73QNQBS X-Message-ID-Hash: QBJY7LUUADHIXZYNUQ3CHI6FA73QNQBS X-MailFrom: crossd@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: =?UTF-8?Q?Michael_Kj=C3=B6rling?= , tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Stdin Redirect in Cu History/Alternatives? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Sun, Dec 11, 2022 at 9:28 AM Steve Nickolas wrote: > On Sun, 11 Dec 2022, Michael Kj=C3=B6rling wrote: > > On 10 Dec 2022 19:22 -0500, from clemc@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 lo= ng > >> 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 " at the prompt, then activate the > > "receive ZModem transfer" function locally; or "rz ", 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.