IRC channel logs

<whitekiba>Heyho. What is the stance of the GNU/Hurd community on LLM-generated code? Because I might have fixed SMP Support in GNU Mach by using LLMs. I have a (as far as i can see) stable Debian GNU/Hurd box running on 4 cores and utilising them all.

<whitekiba>I have somewhat of a software development background but not in OS development. But from my limited view the code looks okayish. And it works without breaking userspace

<whitekiba>Some may remember me from ~13 years ago. I was the guy that wanted to revive Gentoo/Hurd :D I never got it working but i have seen that there have been efforts to get Gentoo working on GNU/Hurd and that got me to come back

<sam_>the fsf position is that llms cannot be used for anything over the boundary of significant for copyright purposes right now

<sam_>but also, smp works already right now?

<sam_>(albeit with some bugs)

<whitekiba>My first tests with the current Git versions of Mach and hurd where unsuccessful. Multiple cores are detected but never used as there are serious race conditions.

<sam_>afaik it's supposed to work with multiple cores already with the exception of translators

<sam_>which get pinned

<whitekiba>"As of September 2024, the SMP support is implemented for i386 with working internet, because it boots with only one cpu in the default processor set. The slave processors are temporarily disabled until they can be safely used per task. We are unable to turn on the full set at boot time due to race bugs. Debian Hurd provides SMP enabled GNU Mach kernels."

<whitekiba>Thats what i have seen on the current version of Debian GNU/Hurd

<whitekiba>It boots, CPUs are brought up but no tasks are scheduled on the other CPUs

<sam_>ah, you can use those by using smp right now, but it is not done by default

<whitekiba>Yes. I tried that but it was highly unstable. No task would run more than a couple of seconds without crashing the system

<whitekiba>Anyway. If someone is interested in looking at what I slopped into existence just poke me. I am not trying to take any credit. It's 99% LLM generated. Just thought it might be useful

<damo22>whitekiba: you could send the patches to the mailing list and mark them as AI generated

<damo22>we could still take ideas from it

<whitekiba>damo22: Thanks. Gonna do that.

<damo22>is it minor changes?

<whitekiba>damo22: Not really. Pretty major changes in Mach. And a few things in Hurd. 800 lines+

<whitekiba>But I am still reviewing. The LLM is trying to get to the root cause

<damo22>hmm ok

<damo22>if you can provide a summary when you mail it in that would be helpful

<damo22>ie why the changes are needed

<whitekiba>I can understand about 70% of the changes. The rest will need someone with deeper knowledge. I willl provide a summary

<damo22>ok

<whitekiba>I will be very clear that the code wasn't written by me.

<damo22>we arent going to merge it as is, but reading a proof of concept as to why smp is broken and how to fix it is useful

<whitekiba>I would like to be able to just contribute to GNU/Hurd but my programming skills are really basic :D

<sam_>nobody was born with them

<whitekiba>damo22: Okay cool. Thats fine. Never thought it would be just accepted

<Gooberpatrol66>to truly erase the authorship of the AI from the patches you might have to do a clean room reverse engineer of them

<Gooberpatrol66>ai code -> specification -> human code

<whitekiba>LLM generated stuff and copyright is a problem. It's something i always think about because LLM generated art is threatening to my community

<nexussfan>Does OpenRC work with Debian GNU/Hurd?

<sam_>answer is the same as last time :)

<sam_>openrc is still a work in progress in debian but a lot of movement on that recently

<sam_>(for linux even)

<sam_>the gentoo stuff for openrc on hurd isn't usptream yet

<sam_>so "no"

<sam_>supporting debian is a bit more awkward because you have /etc/init.d/ scripts which are NOT openrc init scripts

<sam_>that's what all the work in #openrc has been about recently with someone from debian hashing it out

<nexussfan>OpenRC works with Devuan on my machines

<sam_>okay, supporting it well in debian in a manner suitable for upstreaming, not in devuan

<sam_>but all I can say is both the state of our hurd patches for it and also the debian stuff ongoing upstream in openrc

<sam_> https://bugs.debian.org/1132024 also strays into this

<paculino>nexussfan, there was a devuan-hurd channel. I do not know how long ago anyone attempted that, but you might want to try talking to some people from there if you haven't already. You have already met them all anyway

<rsmarples>sam_: any chance i could get a new x86 image with the new glibc please? my poor vm just stops every time I try and build glibc

<rsmarples>alr, im now happy with my bpf code

<rsmarples>it's just a shame that mach_msg isn't a pthreads cancellation point

<youpi>rsmarples: isn't it?

<youpi>I mean, mach_msg is interruptible

<youpi>so you should be able to interrupt it

<rsmarples>not with pthread_cancel() i can't

<youpi>*

<youpi>$*µµµµµµµµµµµµµµµµµµµµµµµµµµµµµµµµµµµµµµµµµµµµ********************************************µµµµµµµµµµµµµµµµµµµµµµµµµµµµ******

<rsmarples>youpi has been hacked!

<rsmarples>maybe he runs a FreeBSD host? https://bumsrake.de/

<youpi>ah, sorry, I was walking with my laptop

<damo22>rsmarples: did you take a look at net-rump.c ? curious if you found anything wrong with it?

<rsmarples>damo22: no, not yet

<damo22>when i strain the driver with lots of rcv packets, something goes wrong

<rsmarples>when i strain my cpu with building glibc something also goes wrong :)

<damo22>is that with smp or uniprocessor?

<rsmarples>i will try building on x86 emulation on my macbook neo. might take a few days/weeks/etc

<rsmarples>smp. is there a smp issue?

<damo22>yes

<damo22>smp is not stable yet

<rsmarples>ok, i wll disable smp and try again

<damo22>but it only applies if you use the gnumach compiled with --enable-ncpus > 1

<damo22>and emulate more than one core

<rsmarples>sam_: is gnumach compiles with --enable-ncpus > 1?

<rsmarples>i hope -smp -cpus=1 is good enough

<damo22>i use -smp 1 with qemu quite often

<damo22>rsmarples: it is nice to have a netbsd fellow here, do you happen to know the status of rump upstream? pooka seems to have disappeared from maintaining it?

<rsmarples>yup, needs a maintainer

<rsmarples>same for nvmm and npf

<rsmarples>for us though it all mostly works

<rsmarples>so low maintaince

<youpi>rsmarples: even in async type ?

<youpi>with async type, the thread_abort() call of pthread_cancel should be able to interrupt mach_mcg

<rsmarples>youpi: that's my workaround, setting async cancellation of mach_msg works fine.

<rsmarples>youpi: it just means I need to take care of some non async-cancel-safe stuff

<youpi>you can enable async just before the mach_msg call

<rsmarples>hmmm

<rsmarples>same numnber of loc, but probably better for brain to process

<rsmarples>i will test

<rsmarples>damo22: nope. just a git checkout of the glibc sourceware repo consitently kill t

<rsmarples>testing without -smp 1 now

<sam_>rsmarples: right now we dont pass ncpus at all

<sam_>we havent played much with smp yet

<sam_>or, wait, hm

<sam_>maybe someone did but locally, i don't see it in the repos anywhere

<sam_>as for image: yes but maybe at weekend, bit ubsy atm

<rsmarples>weekend is fine for me

<rsmarples>heh, df -k totally fails

<rsmarples>youpi: thanks for the tip - setting async for mach_msg and than back to deferred works a treat

<rsmarples>damo22: sadly with smp not enabled something calls it a day trying to clone glibc

<rsmarples>sam_: ill have to wait for your new image plz

<rsmarples>this massively halts me developing on hurd though

<rsmarples>youpi: i sent a patch to bug-hurd to enforce bpf being 32 bits which reduces dhcpcd compile errors on hurd to zero

<rsmarples>sam_: did you change the amd64 preview image recently? i can't even get it past grub anymore

<rsmarples>anyway - the symptoms in this state are this: network is dead, console is alive but typing is black text. i can interrtupt top and restart it and it works

<rsmarples>black text on a black background makes jack a dull boy

<sam_>rsmarples: i'll maybe be able to bang one together tonight/tomorrow morning

<sam_>we'll see

<sam_>no

<rsmarples>ooooo hammering enter got me a prompt back

<rrq>I'm trying setsockopt with ... IPPROTO_IPV6, IPV6_RECVPKTINFO .. which fails. Anyone been there?

<rsmarples>rrq: good luck as IP_PKTINFO fails for me also

<rsmarples>rrq: do you also get a bogus cmsg with type and code being zero

<rsmarples>?

<rrq>don't know yet just started testing... (own program "rrqnet")

<rrq>IPPROTO_IP, IP_PKTINFO for anip4 socket doesn't fail setsockopt

<rrq>ACTION will test ipv4 first

<rrq>mmm "Opening /dev/net/tun: Not a directory" ...

<rsmarples>rrq: don't fail setsockopt doesn't mean they work ;)

<rsmarples>grrr, tmux won't compile and screen just fails

<rrq>yes... now I wonder whether there is a tuntap interface (translator)

<rsmarples>i will try compiling glibc on the console rather than over ssh

<rsmarples>yeah, my guess is that pfinet just calls it a day

<rsmarples>and i can't restart pfinet

<rrq>(I see it's netdde that my code expects should service /dev/net/tun )

<rrq>hmm were's netdde source?

<rrq>hmm debian-ports unreleased/main doesn't have the source package for me :(

<rrq>more hmm: netdde version is 0.0.20200330-12+bin.1

<rrq>how do I translate an cloning ssh url "git.savannah.gnu.org:/srv/git/hurd/incubator.git into a cloning https url (as I don't have ssh access)

<rrq>?

<rrq>:( it's no longer available; netdde translator that handles /dev/net for me .. anyone has any pointer? is that

<rrq>has it morphed into some other "net" project?

<rrq>is git.savannah.gnu.org the place to look?

<rrq>should maybe be a "/hurd" in it?

<rrq>ACTION found something

<rsmarples>alright team, one final issue is i get a lot of `dhcpcd has destroyed a bogus port`. how can i track this down? I get this even with using NO mach specific code

<rrq>having fund the netdde source, I think I need to upgrade it to the current kernel.. i.e. a linux kernel corresponding to current (my( hurd "kernel"

<rrq>the source README talks about linux 2.6.32.59 ... but I assube we'd be looking at something later

<youpi> http://snapshot.debian.org/archive/debian-ports/20200331T085508Z/pool-hurd-i386/main/n/netdde/netdde_0.0.20200330.orig.tar.gz

<rsmarples>well, pfinet is based on 2.2 ...

<rrq>afaui netdde uses linux driver code straight up so the main concern is that the ioctl's (kenrl interactions) are at parity

<rrq>or am I upside down ?

<rrq>to get tap working, I had to remove the /dev/net symlink to netdde and instead make it be /dev/net/tun

<rrq>then I get "ioctl(TUNSETIFF): Inappropriate ioctl for device" ... i.e., my program tries that ioctl on an fd gotten from /dev/net/tun, but that fails

<rrq>so I started to worry about the driver code (tun.c) being more than years old

<rrq>ACTION should relly diff the dource with newer linux source

<youpi>tun should just work, you just need to touch /dev/tun0 , then tell pfinet to use it, then you can open it and ioctl on it

<youpi>apparently the contributor of tunnel.c inside pfinet didn't document how to do it

<youpi>but basically you need to add -i /dev/tun0 to the pfinet translator command line

<youpi>which you can do dynamically with fsysopts

<youpi>there's an example in the wiki, using a differnt pfinet instance, for a pure-user-level vpn

<rrq>thanks. I need to digest that :) .. but I should forget about netdde ?

<youpi>what for?

<youpi>netdde provides harddware drivers

<youpi>there's no need for that for a tun

<youpi>which is entirely software inside pfinet

<rrq>it includes tun.c code

<youpi>we don't use that

<rrq>k yes I followed the linux approach..

<youpi>hurd is not linux

<youpi>"tun" is not a driver really

<youpi>so it doesn't belong to a driver translator

<rrq>yes. just my software is for linux and I wanted to avoid porting :)

<rrq>ok.. would netbsd or openbsd have some applicable docs?

<youpi>no

<youpi>really it's completely different

<youpi>again it's /dev/tun0

<youpi>and you want to pass -i /dev/tun0 to pfinet

<youpi>and then you can open /dev/tun0 and work with that as a normal tun device

<rrq>(I actually want a tap i.e. level 2)

<rrq>same thing I guess

<youpi>no, it's a different level

<youpi>I have to think

<youpi>you want it plugged to the system tcp/ip stack?

<youpi>I don't see it supported in pfinet's tunnel.c but it would be really about just a few dozen lines from getting implemented

<rrq>ta.. I'll try that avenue (tomorrow; it's bedtime)

<youpi>(see how tunnel.c's io_write handler directly pushes as ip packet, while ethernet.c's demuxer pushes as whatever packet the ethernet header says it is, it's really a matter of doing the one or the other in tunnel.c)

<rrq>right; I think the linux tap protoccol adds a 4-byte size before the packets

<youpi>in addition to the ethernet header ?

<rrq>I think so yes... (now I'm not sure) it allows bulk transfers as well I think

<rrq>no.. that was the alternative stdio channel

<rsmarples>ok, so on my vm lwip just fails to work for git clone - ping and dns work fine to my router though

<rrq>the host is masquerading?

<rsmarples>and my macbook took a day just to install sudo

<rsmarples>rrq: what is masquerading?

<rrq>NAT

<rsmarples>that would be a yes

<rsmarples>rrq: i develop a DHCP client and server. I always test on VMs in my little homelab and routing /translation isn't an issue for me

<youpi>do you have hardware virtualisation enabled?

<rsmarples>youpi: yes

<youpi>a day for installing a package is definitely out of any normal condition :)

<rsmarples>youpi: ah on my macbook, no i don't - unless hurd magicallh supports arm64 ;)

<youpi>ah, then it's much less surprising

<rsmarples>on my netbsd host yes i use nvmm in netbsd for accelleration

<youpi>there happens to be some efforts on arm64 support

<rsmarples>youpi: is there a pre-installed image anywhere?

<youpi>it's far from that for now

<rsmarples>well, it's getting to the point where hurd feels like that for me :(

<youpi>but once the (micro-)kernel support is finished, it could be quick to be available

<rrq>hmm wheres pfinet source ? ...

<youpi>in the hurd package

<rrq>ta

<rsmarples>i can't get debian/hurd to run at all on my netbsd box, only gentoo x86 works and that fails hard when straining the network

<youpi>at all?

<youpi>what happens?

<youpi>I mean, th ebuildd boxes build packages all day long...

<rsmarples>youpi: it fails it displayinf anything post grub

<youpi>what virtualization software is that?

<rsmarples>qemu on NetBSD

<youpi>that's extreemly odd, since gnumach simply uses a very simple vga driver

<youpi>and gentoo uses essentialyl the same source as debian

<rsmarples>right, but it doesn't change the console to "vga"

<youpi>?

<youpi>it doesn't need to, a normal pc boots with vga

<youpi>otherwise it's not a normal pc

<youpi>at best it'd be an efi pc

<rsmarples>youpi: so gentoo doesn't change the font post grub, debian does. that is the visual difference i see and that's all i know

<youpi>changing the font?

<youpi>I mean, do you have gnumach messages?

<youpi>there is no font change involved there

<rsmarples>last i chcekd no

<youpi>there's something really odd with your virtualization software then

<rsmarples>let me spin another one up, few moments

<youpi>gnumach is just writing ag 0xb8000

<youpi>that's really *just* supposed to work on a normal pc

<youpi>just an odd idea, how much ram do you give it?

<Pellescours>When the font changes, I think it’s because it’s the hurd console that starts

<youpi>yes

<youpi>no output at all means it's gnumach itself that doesn't boot

<rsmarples>qemu-system-i386 -accel nvmm -cpu host -rtc base=utc,clock=host -device ahci,id=ahci -device ide-hd,drive=disk13,bus=ahci.0 -drive file=hurd2.qcow2,if=none,id=disk13 -object rng-random,id=rng13,filename=/dev/urandom -netdev tap,ifname=tap13,id=net13,script=no,downscript=/home/roy/qemu/qctrl-tapdown -device 'ne2k_pci,romfile=,netdev=net13,mac=52:54:00:73:00:0d' -vnc ':13,password' -monitor

<rsmarples>'telnet:127.0.0.1:4413,server,nowait' -pidfile /home/roy/qemu/run/qemu-hurd2.pid -daemonize -m 2G

<rsmarples>and the debian pre-inst says hd0 can't be found

<youpi>the preinstalled image assumes an ide disk

<youpi>the readme file is called readme for a reason :)

<youpi>if you step out of it, you're in danger

<rsmarples>i am looking at a web page

<rsmarples>not a readme

<youpi>which webpage?

<rsmarples> https://www.debian.org/ports/hurd/hurd-install

<youpi>ok, I'll add a note there

<rsmarples>ok, new commandline

<rsmarples>qemu-system-i386 -accel nvmm -cpu host -rtc base=utc,clock=host -drive file=hurd2.img,cache=writeback,format=raw -object rng-random,id=rng13,filename=/dev/urandom -netdev tap,ifname=tap13,id=net13,script=no,downscript=/home/roy/qemu/qctrl-tapdown -device 'ne2k_pci,romfile=,netdev=net13,mac=52:54:00:73:00:0d' -vnc ':13,password' -monitor 'telnet:127.0.0.1:4413,server,nowait' -pidfile

<rsmarples>/home/roy/qemu/run/qemu-hurd2.pid -daemonize -m 2G

<rsmarples>i now see hurd entering init 2 and my qemu promptly crashes

<youpi>it's qemu that crashes ?

<youpi>well, the guest can't do much :)

<youpi>but does it not say in which part of its code it crashed?

<youpi>as in: is that a virtual device assertion, a memory management issue, etc.

<rsmarples>alr, progress. if i disable everything and just use vanilla i386 it boots but it's no faster than my macbook at this point

<youpi>you have disabled acceleration as well?

<rsmarples>also, a pox on debian dhclient being rfc incompliant with option 119

<rsmarples>youpi: sadly yes

<youpi>so it's not surprising that it's as slow as emulation on macbook

<rsmarples>no, it's not

<youpi>with acceleration it crashes ?

<rsmarples>yes it does

<rsmarples>on amd 3900x cpu w oodles of ram

<youpi>I guess running hurd on netbsd has never really been tried

<rsmarples>i eat my own dogfood :D

<youpi>and it thus exercises nvmm and then triggers bugs that people had never seen

<youpi>we've already seen that in a few virtual devices in qemu

<youpi>they are fixed into running linux drivers, but not much other drivers

<youpi>when using the netbsd drivers inside rump, we are more protected by the netbsd testing

<youpi>but for memory management, mach is quite different from the bsd kernels, even though sharing a common base

<rsmarples>well, things must have been fixed a little as the gentoo image "works" with nvmm acceleration and all my other bells and whistles until i put strain on anything network related

<youpi>you could try a more recent preinstalled image from https://cdimage.debian.org/cdimage/ports/latest/hurd-i386

<rsmarples>bah, i can't even get qemu working on my one linux host

<rsmarples>(it's bazzite, i enjoy games)

<rsmarples>no, im done with this. three different machines none can boot hurd to a useable level.

<rsmarples>I'll wait for a new image from sam_ to verify the AF_LINK and friend being gone and I'll publish my changes and call it a day]

<rsmarples>kbd queue full running i386 vm with no accelleration on a linux host

<rsmarples>mouse queue full

<diegonc>that's the hurd console timing out before fully initializing, emulation is too slow for that :(

<rsmarples>hmmmm, so emerge sudo just got stuck on my mackbook. the session lockd up, but otherwise it still works

<rsmarples>sigh

<Pellescours>youpi: for this patch https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/hurd-i386/unsubmitted-getaux_at_secure.diff the comment says "should instead pass an auxv

<Pellescours>to __libc_start_main

<Pellescours>"

<Pellescours>Does it mean that we should define HAVE_AUX_VECTOR ?

<Pellescours>Otherwise the patch can check "#ifndef HAVE_AUX_VECTOR \n if (type == AT_SECURE) { ... } #endif. What do you think?

<Pellescours>(because there is already a HAVE_AUX_VECOR, so we can use this property to have nice implementation in __getauxval2)

<youpi>Pellescours: not sure to understand what you mean. We currently don't pass an aux vector to main, we really should (there are a couple other auxv elements that are needed nowadays)

<youpi>and then we'd indeed define HAVE_AUX_VECTOR, but that's just a side effect

<youpi>the point is to provide things in standard ways (rather than the __libc_enable_secure variable)

<Pellescours>ok, that’s what I wanted to know. Thank you.

IRC channel logs

2026-06-11.log