Re: Come watch a live stream coding session for the Hurd Video

[Sergey Bugaev <bugaevc@gmail.com>]

On Sun, Jun 2, 2024 at 12:22 AM Joshua Branson <jbranso@dismail.de> wrote:
> So we had an awesome time today watching Sergey code a trivial translator (1) and do
> some glibc hacking (2).  Sergey coded and chatted for 4 and 1/2 hours!  Three cheers
> for that kind of commitment!  Thanks pal!
>
> In the livestream today, Sergey wrote caesar.c, which implements a simple caeser
> cipher. It's a toy. A caesar cipher is EASY to break, but it was fun watching
> him code it out!

Hi all,

thanks for attending, and thanks Joshua for organizing it!

Let's do this again sometime? -- hopefully with less technical issues
related to recording/audio/video. I've got plenty of exciting ideas of
things to do. There are projects I started but haven't completed, like
the new bootstrap process (that Josh keeps calling "serverboot v2") or
the new in-tree, Hurd-native libfuse (which is an full translator
framework in its own right, a peer to libdiskfs/libnetfs/libtrivfs,
but mostly API-compatible with the Linux libfuse), or epoll/Wayland
(which is mostly complete, but it needs to be updated / cleaned up,
and published). Or, we could get started on writing that shiny new
translator framework in Rust :)

We ended the stream on a somewhat of a cliffhanger: can we run
caesarfs (see, Joshua misspelled it too, so it's not just me!) on the
aarch64-gnu system? The process was getting created, but then it
crashed before it got a chance to handshake with its parent translator
(root ext2fs), and thus fake-console-run.c was getting EDIED trying to
open the file. Turns out, we need to explicitly null-terminate the
last argv entry too when setting a static translator record from my
GNU/Linux host, so instead of
$ sudo setfattr -n gnu.translator -v
'/hurd/caesar\000/libexec/hello-world.txt'
/mnt/libexec/hello-world.txt.csr
I should have done
$ sudo setfattr -n gnu.translator -v
'/hurd/caesar\000/libexec/hello-world.txt\000'
/mnt/libexec/hello-world.txt.csr

It was crashing inside ld-arrach64.so.1 trying to parse its argv,
since it expected them to be in the argz format, so null-terminated.
(Did I mention how incredibly useful being able to backtrace through
syscall/fault/interrupt boundaries is for debugging?)

With that fixed (no changes to the translator itself, but the
translator record changed as shown above), I do get:

GNU Mach 1.8
Kernel command line: foo=bar
Booting in EL1
vm_page: page table size: 262144 entries (20480k)
vm_page: DMA: pages: 262144 (1024M), free: 221873 (866M)
vm_page: DMA: min:13107 low:15728 high:26214
Model name: linux dummy-virt
module 0: rootfs $(rootfs-device=ramdisk-create)
rd0: 36700160 bytes @ffff000083424000
module 1: ld-aarch64.so.1 /hurd/exec $(exec-task=task-create)
module 2: ext2fs --host-priv-port=${host-port}
--device-master-port=${device-port} --exec-server-task=${exec-task}
--multiboot-command-line=${kernel-command-line} -T device
${rootfs-device} $(task-create) $(task-resume)
3 bootstrap modules
task loaded: ld-aarch64.so.1 /hurd/exec
task loaded: ext2fs --host-priv-port=1 --device-master-port=2
--exec-server-task=3 --multiboot-command-line=foo=bar -T device rd0

start ext2fs: Hello world!
fread () -> 5
Uryyb

"Uryyb" is of course "Hello" with ROT13 applied :) So we were very close.

Sergey