June 2, 2024 at 12:50 PM, "Sergey Bugaev" <buga...@gmail.com> wrote:
> > On Sun, Jun 2, 2024 at 12:22 AM Joshua Branson <jbra...@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 https://darnassus.sceen.net/~hurd-web/open_issues/serverbootv2/ > 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 :) I'm game to watch you code any of those projects! 2pm UTC works really well for me. Shall we have another live hacking session on another Saturday at 2pm UTC in about two months? Sooner? Later? > 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 Do we want to commit caesarfs the Hurd? It is fairly simple and maybe not really useful...but maybe yes just 'cause ? Maybe that should be left as an exercise to me or someone else ? Anyone else need some extra homework? Joshua