IRC channel logs

<jab>sneek: later tell solid_black does your ipfs still outperform linux's ?

<sneek>Okay.

<gnucode>I sort of wonder where I should document the "ext3/4fs" feature. Maybe I should also only call it "ext3fs".

<gnucode>I suppose until there is a better spot, ext2fs on the wiki is probably the best spot for it.

<gnucode>And I can currently edit the wiki via the web interface. 1 to me. 0 to the AI bots slowing down that site.

<rsmarples>ok i killed the network stack on x86 doing a lan transfer of a small file

<rsmarples>my local dhcpcd now compiles on hurd with *minimal* changes to the source

<rsmarples>it's just telling dhcpcd it's not a BSD and AF_LINK and SIOCAIFADDR don't exist

<sam_>\o/

<sam_>rsmarples: have you found x86 a bit better?

<rsmarples>sam_: no

<sam_>lol

<sam_>i'm surprised (and disappointed)

<rsmarples>sam_: while i can emerge git (yay), i can't emerge vim

<rsmarples>bails compiling libsodium

<sam_>does it look package related or general death again?

<rsmarples>death testing if it can capture a signal in configure

<sam_>I remember seeing that and finding it interesting, iirc it traps waiting for a debugger

<sam_>I think there's a way to disable that behaviour with a translator

<rsmarples>and scp'ing a git repo on the host kills the network reliably

<rsmarples>and as there is a disagreement with upstream libpcap and debian hurd, i am looking at writing bpf-hurd once i fix the remaining bugs

<rsmarples>as i recall it's tricky to put patches into 9999 builds?

<yelninei>For libsodium and others i had an issue with crash-dump-core on 64bit with SIGABRT before

<rsmarples>as I can't stand nano, a lack of vim is a big issue for me :/

<rsmarples>sam_: don't feel bad though - at least the gentoo images actually boot on one of my hosts

<solid_black>Gooberpatrol_66: the question was, would you be interested in hacking on it ;)

<sneek>Welcome back solid_black, you have 1 message!

<sneek>solid_black, jab says: does your ipfs still outperform linux's ?

<solid_black>it's very incomplete, it needs people to work on it

<solid_black>although I suppose it works well enough for read-only access, in that you can browse and read files

<solid_black>but even mmap (io_map, libpager etc) are not implemented

<solid_black>plus, all the writing -- io_write proper, all the direntry manipulations...

<rsmarples>ok. so it looks like the network ioctl sucks balls - can't use it to set netmask for example - gets EPERM.

<rsmarples>so im guessing the "hurd way" is to use settrans /hurd/pfinet and configure that

<sam_>yes

<rsmarples>alr, so the patch for the hurd backend to dhcpcd is useless

<sam_>well, I dunno if it's supposed to work, I just know everyone uses settrans ;)

<solid_black>fwiw, to configure an already running translator, what you'd use is fsysopts, not settrans

<sam_>oh right

<rsmarples>only one global ipv6 address? how ..... limiting

<rsmarples>solid_black: looking at the debian page, fsysopts isn't persisent whereas settrans -fgp is?

<rsmarples>so questions

<solid_black>these are really two different things

<solid_black>one tells the running translator, hey, apply these new options on the fly

<solid_black>the other one terminates the old translator, and saves to disk the new options

<solid_black>for the new instance of the translator will be presumably started on demand

<rsmarples>can i run two pfinets on different interfaces with the same ip address and/or subnet and if who which one takes precedence for outbound?

<solid_black>in the context of a network stack, you likely don't want to save DHCP config onto disk (right?), and you don't want your network to go down because of a reconfig

<solid_black>1. I don't know

<solid_black>2. I expect you to be able to run as many as you like

<solid_black>2. when you call socket(PF_INET), glibc talks to /servers/socket/2, so whichever pfinter is sitting on that node wins

<solid_black>that was meant to be 3. obviously

<solid_black>does that make sense?

<solid_black>a real serious network stack should of course be able to accomodate multiple interfaces and multiple IP addresses in the same instance

<rsmarples>correct

<solid_black>don't know how capable is pfnet vs lwip vs whatever alternatives there are

<sam_>wait

<sam_>are we sure the dhcpcd backend doesn't require lwip?

<sam_>i thought it did

<rsmarples>what is lwip?

<solid_black>lwip in the context of hurd is an alternative tcp/ip stack for the hurd, based on lwip the project

<sam_>fullblown userland tcp/ip stack

<sam_>i haven't yet tried to use it

<solid_black>lwip the project is a presumably-lightwight tcp/ip stack implementation

<sam_> https://lists.gnu.org/archive/html/bug-hurd/2026-04/msg00067.html ah, this talks about pfinet too, but also lwip

<sam_>it looks like lwip was the focus

<rsmarples>well, the patches don't work. I get EPERM trying to set anything other than the address

<solid_black>alright, there we go, I made 9pfs repo public! https://github.com/bugaevc/9pfs

<solid_black>please DO NOT send github issues or prs, send feedback and patches to the mailing list instead

<solid_black>let me post to the list as well

<rsmarples>so if libc only uses /servers/socket/2 for networking, there's little point in doing anything else, so while you might be able to run many pfinets, only one will actually work for userland

<solid_black>yes

<solid_black>well, different processes can have different ideas of what /servers/socket/2 is

<rsmarples>ok

<rsmarples>how do i remove a translator?

<diegonc>settrans

<diegonc> -g goaway

<diegonc> -a active

<diegonc> -p passive

<diegonc> -f force

<rsmarples>ok, that's enough to use settrans in a hook script

<rsmarples>ah balls

<rsmarples>i now have a chicken and egg problem

<rsmarples>ok, now i understand

<rsmarples>all socket operatons go through pfinet

<rsmarples>including the calls to iterate interfaces

<rsmarples>if getifaddrs(3) won't work without pfinet then we'll need a mach backend instead

<diegonc>I don't think mach has any idea of what network interfaces are there in the system

<rsmarples>well, something has to

<rsmarples>for example on solaris I would use dlpi to work this out as getifaddrs doesn't list hardware addresses either

<rsmarples>it seems i can start pfinet with all zero addresses, but it then sends from all zero addresses which will confuse the shit out of some network stacks

<rsmarples>but maybe I can use that to my advantage - why bother with BPF?

<rsmarples>I mean sure ARP won't work (in dhcpcd) but everything else will

<etno>Hello everyone ! I'd like to fix an app on the Hurd, and it wants to know how much memory is available.

<etno>The linux implementation is using sysinfo(). What would be the best way to retrieve this bit on the Hurd ?

<etno>top seems to use libproc2

<azert>rsmarples: if you think something should know about enumerating network interfaces, that would be pfinet

<azert>etno: alternatively you can check what procfs is using

<rsmarples>azert: and how does pfinet enumerate interfaces and get the hardware address?

<etno>azert: yes, there are a few places where the info is available, but I wonder what is the "right" level

<azert>does it do that? I don’t think so

<etno>We could want to implement `posix_typed_mem_get_info()`

<etno>No, that doesn't match

<etno>So I hesitate between reading /proc, using libproc2, or doing a gnumach call

<jab>howdy people!

<diegonc>o/

<rsmarples>ok

<rsmarples>sa_len in hurd is a good joke right? It's zero in a call to get the hardware address. How do I know how long it's supposed to be?

<youpi>it probably simply just got buggy when $somebody plugged the linux network stack in pfinet while the hurd was supposed to be providing a bsd interface

<youpi>patch welcome

<rsmarples>where do i find this lwip?

<diegonc> https://cgit.git.savannah.gnu.org/cgit/lwip.git

<diegonc>beaware though that it's target AFAIK is embedded systems, so may lack some functionalities

<rsmarples>diegonc: thanks

<rsmarples>i think my question was more "where is it in a debian hurd install?"

<rsmarples>or is it not?

<diegonc>oh, yes there is a translator in the hurd.git repository that wraps the library

<diegonc>but you need to install dependencies and enable it somehow

<diegonc>i.e. a configure flag. Sorry, I haven't investigated much about the plumbing

<rsmarples>sam_: do you know if gentoo enabled lwip?

<sam_>we haven't yet, i wasn't clear on if it was ready for playing with

<sam_>i wanted to get netifrc ported first

<rsmarples>mmmm

<sam_>/want

<sam_>otherwise we're juggling lots of scripts to setup net

<rsmarples>ok, so we may need different backends then as i can't test lwip until it's in gentoo

<rsmarples>no matter, a pfnet backend for dhcpcd is likely doable

<rsmarples>holy crap, DHCP transactions are happening!

<diegonc>\o/

<rsmarples>so assuming lwip also works on socket/2 I will need a way in userland to distinguish between the backends

<sam_>\o

<sam_>\o/

<rsmarples>ok, so joans libpcap actually works fine once I got the interface hardware address working, that is good news

<Gooberpatrol_66>\o/

<rsmarples>sam_: you know i wrote the bulk of netifrc and openrc right?

<sam_>i do :)

<sam_>(but i wasn't saying it to bait you into it)

<rsmarples>sam_: for dhcpcd to work with pfinet, I'll need net.eth0 to do the grunt work of bringing it up with the 0.0.0.0 address

<rsmarples>I will write that tomorrow, or when i get back from the pub

<sam_>thanks

<sam_>I don't have much time for hurd at the moment but I can try find some to package lwip

<rsmarples>that would be helpful for me

<rsmarples>SIGBEER

<rsmarples>sigh, no hurd support for netifrc :/

<sam_>that's what i was telling you!

<sam_>nearly done packaging lwip at least

<sam_>handling hurd support in netfirc was/is one of the next big things to do

<sam_>ok, lwip packaged and hurd has a USE=lwip now, but not tested at runtime (just cross so far)

<rsmarples>sam_: thanks!

<rsmarples>ill probably get to lwip next week ish

IRC channel logs

2026-06-03.log