IRC channel logs

<rrq>solid_black: I pushed the wip/hurd-trial branch with revision to allow hurd API for the tap (by recognising the tap name as starting with /)

<rrq>your streamio advise seem good, but I'm unsure about which driver node to use.

<rrq>all I've guessed a few variants but all hang on open

<damo22>why cant you just connect to /dev/netdde?

<damo22>or devnode -M eth0 /dev/netdde or somethingf

<damo22>ie connect your tunnel to /dev/eth0 ?

<rrq>tried those, with a streamio intermediate, but it just hangs on open()

<rrq>"fd = open( dev, O_RDWR )" hangs

<rrq>I believe streamio translates that into a "device_open(...)"

<rrq>but something more/else is required

<rrq>btw is there somehting similar to "netstat" or "ss" .. where I can see net services ?

<rrq>ok; i can verify the UDP service with nc

<rrq>I just need the ethernet level I/O channel :(

<rrq>ideally without needing a "hurd porting" ... though would merely require me to learn the hurd device level I/O I guess

<rrq>on hurd, /dev/eth0 is a /hurd/devnode translator with "-M /dev/net"... and /dev/net is a symlink translator for /dev/netdde .. and /dev/netdde is a /hurd/netdde translator

<rrq> /dev/eth0 = /hurd/devnode -M /dev/net eth0

<rrq>I guess it's all revealed in the netdde code

<rrq>ah, so [ settrans -cfap /dev/tap0 /hurd/devnode -M /dev/net eth0 ] and [ settrans -cfap /dev/tapS0 -- /hurd/streamio -w /dev/tap0 ] gives me what I want

<rrq>thanks solid_black, that really is exactly what you said that there's nothing new needed for tap device.

<rrq> /dev/tap0 = /hurd/devnode -M /dev/net eth0 ... invents a tap0 device (with device I/O)

<rrq>then /dev/tapS0 = /hurd/streamio -w /dev/tap0 ... offers stream I/O for it

<rrq>and then I can ifconfig /dev/tap0 to have a second (VPN) interface

<rrq>actully still hangs on open :(

<rrq>actually still hangs on open :(

<rrq>seems to loop in _hurd_intr_rpc_mach_msg

<rrq>called from dir_lookup

<rrq>not busywait, but a -25 syscall return point

<Gooberpatrol66>just discovered this https://github.com/J-x-Z/hurd-xnu

<azert>Gooberpatrol66: did you try it? Does it work? Is it slop?

<azert>the dude even added a GPL-2.0 license.

<azert>making his code unusable

<rrq>solid_black: my tap0 setup doesn't work since the new interface gets the sam mac address as the referred

<rrq>eth0

<rrq>I haven't found a way to make it have a different mac

<rrq>so I think it's back to needing a translator of its own, or something

<rrq>which git repo is used for building netdde ?

<damo22>Gooberpatrol66: isnt xnu missing all the iokit drivers?

<damo22>ie the driver modules that actually make hardware work are not included, but might be binary compatible with macOS binary kexts?

<damo22>LKL is interesting though

<damo22>i wonder if we can use LKL in Hurd to provide a monolithic set of drivers, but attach separate translators to them

<damo22>it would work, but wouldnt be very hurdish

<damo22>so, the hardware support could be in one fat library, but we still fan out the translators to run the operating system

<damo22>work could be done to split it up, i guess

<damo22>i wonder if its possible to compile LKL with just one family of drives

<damo22>drivers

<damo22>eg, all of gfx

<damo22>then do it again for net

<damo22>etc

<rrq>anyone knows where netdde source repo is?

<damo22>hmm its definitely in salsa i would imagine

<rrq>ah yes I haven't looked in salsa

<damo22>i managed to compile LKL with drm only and pci, i could try to replace the pci support with libpciaccess :D

<damo22>-rw-rw-r-- 1 demo demo 125665792 Jul 11 20:45 lkl.o

<damo22>thats with full debugging symbols and trace support

<azert>LKL looks like a dead project to me

<azert>but could be something useful for certain hw support

<azert>the Hurd xnu looks more like a compatibility layer and a partial reimplementation then a port of the Hurd to xnu

<azert>that said, it’s probably not that much work to port the Hurd and glibc to xnu, since most Mach rpcs are already there with the same semantics

<azert>I wonder why the author didn’t just do that. My guess is that it just doesn’t compile because of missing bits

<sam_>unfamiliar with lkl

<sam_>what is it?

<azert>The equivalent of rump for linux

<azert> https://github.com/lkl

<azert>well, it’s definitely not dead

<azert>would indeed be a great way to port gfx drivers to the hurd

<damo22>it is a first class target for the linux kernel

<damo22>ARCH=lkl make menuconfig

<damo22>so you can strip out everything except one class of driver

<damo22>rinse and repeat

<azert>I bet lkl supports loadable modules

<azert>would make sense to use them to reduce the size of the binary

<damo22>with nothing except drm its 120M

<damo22>with debug symbols etc

<damo22>i dont think loadable modules will fix that

<azert>I am wondering if that includes both nvidia as well as amd and intel

<azert>and a few others

<gfleury>sneek later tell solid_black i was able to build epoll-hurd and run some tests. Thanks

<sneek>Will do.

<damo22>im not sure i didnt see it compile that in

<damo22>maybe it was missing the gfx hw layer

<azert>indeed

<damo22>it has drm infra

<damo22>maybe not the hw impl

<azert>how do we wire that up? I remember it was discussed to emulate ioctls in glibc or to use vm_read to copy memory across tasks

<azert>we could also implement vm_read_overwrite that was implemented in osf Mach

<azert>equally interesting is vm_remap

<azert>all this has the issue that in the Hurd the server doesn’t get the task port of the client performing the ioctl

<azert>a part implementing the ioctls in glibc of course

IRC channel logs

2026-07-11.log