IRC channel logs
2026-06-04.log
back to list of logs
<rsmarples>sam_: so i slept on the idea and I don't think porting to netifrc is the right way here <azert>rsmarples: pfinet is eventually going to be deprecated and discardes <azert>but in the meantime, we don’t want different apis for pfinet and lwip. Everything should work on both <rsmarples>but an init.d script for pfinet will work just fine <rsmarples>grrrr, something is blocking. every command just doens't return <rsmarples>sam_: what do i need to emerge to get /hurd/lwip? <rsmarples>boooo, pfinet won't let me send DHCP messages from 0.0.0.0 to 255.255.255.255. So BPF is a requirement. <rsmarples>as libpcap usptream is arguing over what i need for hurd, i wonder how hard it would be just to lift what I need into dhcpcd? <sam_>rsmarples: sys-kernel/hurd lwip in /etc/portage/package.use, then emerge -v1 hurd <sam_>as for an init.d script: yeah I guess, I just figured people wanted a consistent experience <sam_>and debian already ported their version of it <sam_>that said netifrc just for lwip would be fine with me of course but i expect it to mostly work the same, though i haven't tried it yet so maybe i'm wrong <sam_>(if you look at what ifupdown does, it calls ifconfig (from inetutils) a bunch) <rsmarples>sam_: the issue is that for pfinet at least, the ifconfig tool is "read only" <rsmarples>sam_: but the deal breaker for me is semantics. pfinet is the whole stack - there is no "lo0" or "eth0" directly available via ioctl. <rsmarples>once I get lwip up and play with it, then porting netifrc might be a better idea at that point <mlxdy>Helllo, anyone daily driving hurd? <solid_black>rsmarples: on the topic of listing network interfaces... I was thinking, someone, perhaps you if you're doing this, needs to think this whole model over <solid_black>understand what network interfaces *are* -- in unix, they're a distinct entity, not a file, not a device -- but on the Hurd, they're just an fs node that you can read/write? right? can you use any device as a network interface? <solid_black>understand what tun/tap are and how they plug into this -- on unix, it's a way to bridge network interfaces and devices, but on the Hurd, do we even need that? <solid_black>and maybe come up with a better way to represent this all to the network stack <solid_black>currently if i understand it right, which I might just not, this is managed by providing some --interface argv to pfinet <Gooberpatrol_66>solid_black: i looked at 9pfs. remind me, what was the reason for rewriting it without libnetfs? <solid_black>Gooberpatrol_66: I don't remember the details, but overall, that netfs's model was poorly suited for 9p (and frankly, for other network protocols, so the name netfs is moot) <solid_black>one thing was multi-part path lookups, which 9p can do on the server side, but netfs insists on resolving every part locally <solid_black>another one was that netfs wanted you to put your tracking into netnodes, but what you actually want to do is to put some of it into protid, and possibly some into peropen <azert>solid_black: thank you for the explanations <azert>maybe libnetfs should be called libsysfs or something similar <azert>and if would be cool if a new netfs <azert>iirc the current netfs is troubling for httpfs too <azert>in any case, I wish all your recent contributions will be integrated upstream, or will be packaged in Debian <sam_>rsmarples: ah, I see, I wasn't aware of that <gnucode>mlxdy: I sort of daily drive the Hurd. <gnucode>rather, I run it on real hardware. hurdos.com I use the T420 with 12 or 16GB of RAM. I am using Debian GNU/Hurd. <gnucode>I do not daily drive it, but I use it when I can. <solid_black>azert: without having looked into httpfs, I imagine the same issues I had with netfs in 9pfs are very relevant for httpfs too <gnucode>I made that logo on a Debian GNU/Hurd machine running bare metal with inkscape! <gnucode>sneek later tell azert I think we should change libnetfs -> libdirfs