IRC channel logs

<rsmarples>just a shame no hurd boots on my macbook neo. it would make things easier in my life right now

<rsmarples>(as in the kids cant take this for gmaing)

<youpi>Pellescours: glibc's read() call is essentially an io_read RPC call, so if pflocal's S_io_read really returns 0, there is not much on the path that could be hanging. Putting some mach_print on the path would help determine exactly where this hangs

<etno>Hi ! Some time ago, there has been work done to update the mesa library. Following the trail, it seems that some DRM changes were required and that they should be negotiated with the linux project. How are things going with this plan ?

<solid_black>morning!

<user_oreloznog>\o

<etno>o/

<etno>solid_black: you made me curious regarding this virtio thing

<etno>So this is a kind of mailbox over PCI ?

<solid_black>I don't remember (and then I never was a hardware person), but I think it had multiple "backends", pci being one of them

<etno>Argh, why am I looking at the spec... https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.html#x1-1140004

<etno>PCI, MMIO or Channel I/O

<solid_black>yeah, something like that

<solid_black>everyone loves it, because it's supposedly low-overhead and high-performance

<solid_black>and it became very popular once qemu and linux implemented it

<solid_black>for 9p specifically, I'm not after performance, or in other words we won't be limited by the I/O transport throughput

<solid_black>latency will dominate it rather

<solid_black>but, there is 9p-virtio, and qemu already implements it, and everyone already uses that, so we could just support that as well

<solid_black>with libvirt, you basically put this in your XML: https://wiki.qemu.org/Documentation/9psetup#Starting_the_Guest_using_libvirt

<solid_black>and there you have your host fs accessible via 9p

<solid_black>so then on the Hurd side you'd need 'settrans /dev/virtio-9p /hurd/fictional-virtio-translator --possibly-some-options' and 'settrans /mnt /hurd/9pfs /hurd/fictional-virtio-translator', and that's it

<solid_black>in the long run, I totally wanted 9pfs to be robust and featureful enough to serve as your root fs

<solid_black>so you could store an entire Hurd chroot (perhaps cross-compiled) on your host machine, and just boot your VM off of it

<solid_black>so it needs to support things like multiple users (UIDs), translators, static translator entries

<solid_black>and to be clear, that's nowhere near the state it is in right now, it's more of a toy fs

<etno>Being able to share a host directory at FS level is usually interesting when you want to mess with the network stack. <devil-advocate>What does virtio bring that a subhurd would not ?</devil-advocate>

<solid_black>being able share a directory is useful for many reasons

<solid_black>one of them being, you want to use a GUI editor on the host (e.g. vscode) to edit your code

<solid_black>then either cross-compile on the host or compile in the VM, and definitely run in the VM

<solid_black>without copying things over and back all the freaking time

<solid_black>but also yes, this running over a separate virtio device means that it's entirely non-dependent on teh network stack

<solid_black>so if the network stack gets itself into a bad state, which it so commonly does, your fs stays alive

<etno>On a pragmatic level, I completely agree. Until the day Hurd can be used as the host, reliably 🤓

<rsmarples>etno: working reliably in a vm would be a good part as well :)

<rsmarples>although my hosts are non standard so fault could be there also

<etno>I'm using boringly standard hosts here, and the kind of locks you described happens here as well. I still need to learn how to troubleshoot this kind of stuff.

<rsmarples>and i am so dumb

<rsmarples>hurd boots on my macbook using a serial terminal

<rsmarples>or at least i can see it's stuck at checking the disk

<azert>rsmarples: your macbook has a serial port?

<rsmarples>azert: no, but qemu has a serial port display option

<rsmarples>it's slow as heck (arm64 can't virtualise x86) but it works

<azert>are you emulating the x86 macbook hardware

<rsmarples>emulating the x86 cpu yes

<azert>what about the platform?

<azert>I guess you emulate a pc

<rsmarples>yeah, q35

<azert>I’m surprised it doesn’t just work

<rsmarples>azert: i get a black screen after the grub boot menu

<rsmarples>i get the same issue with NetBSD. both need a serial display

<rsmarples>other OS's I dev on work fine.

<azert>did you try to override the -vga option?

<azert>-vga std

<rsmarples>ok, hurd amd64 crashes with an hpet error in early boot, so it looks like i get x86 only on the macbook

<sam_>the hpet thing is a bug in mach

<sam_>libvirt i think doesn't default to providing hpet, but it insists on it in mach somewhat unnecessarily

<rsmarples>i think gentoo/hurd will be bad on the macbook as emulation is sloooowwww and therefore compiles will be slow

<rsmarples>anyone know if the debian pre-installed image provides a serial boot option like gentoo?

<diegonc>you have to pass console=com0 from the grub commandline to gnumach by editing the menu entry

<diegonc>with virtualbox it works, that's all the testing i've done :P

IRC channel logs

2026-06-09.log