IRC channel logs
2026-06-08.log
back to list of logs
<gnucode>grrr, magit is still acting up on me. <gnucode>process-file: Opening process input file: Computer bought the farm, /dev/null [4 times] <gnucode>that's the error that I see when I try to stage files in magit... <diegonc>gnucode, what does /dev/null have to do with the message error? :/ <gnucode>I just copy/pasted the error message in the Emacs' *Messages* buffer <gnucode>is your question a joke that I'm missing ? <diegonc>sneek later tell gnucode no joke, I'm truly confused why would /dev/null could throw such error or if it is a red herring <rsmarples>ok, I must be doing something wrong I think. <rsmarples>I call mach_port_deallocate, what notification in other thread do I need to listen to for this? <rsmarples>solid_black: hi! you seem to know a lot. do you know anything about mach port notifications? <solid_black>I *have* known a lot, some of which I still rememeber :D <rsmarples>ok, i want to be notified of mach_port_deallocate <solid_black>the one that is sent to a server once there are no more send rights to its port <solid_black>i.e. when all the clients mach_port_deallocate their send rights to the port <rsmarples>the port in question is a receiver from the network BPF <rsmarples>but rather than timeout and test thread cancellation, i want to just block until either a network message is received or the port is destroyed <rsmarples>i can see my code deallocating the port, but i don't see any notification of this deallocation <solid_black>who are you in this case (a client of some bfp translator?), what are you doing (sending out an RPC?) <rsmarples>I am a DHCP client opening a BPF port to the ethernet device <solid_black>okay, so you're opening it, with like file_name_lookup or such? <solid_black>and who's deallocating which port? and who wants to be notified? <rsmarples>ok, so open port, create thread which blocks with mach_msg, the main thread then deallocates the port <rsmarples>i want the thread blocking on mach_msg to be notified of the deallocation <solid_black>is the mach_msg blocked on receiving the response, not sending the request? <solid_black>cannot the main thread just notify the other thread directly, if they're a part of the same program? <rsmarples>mach_msg is blocked - i need a mechanism to interupt it <solid_black>...I suppose things like pthread_cancel won't help here, right <damo22>if mach_msg is blocked on response, and the port is deallocated, wont it return early if the port is destroyed? <solid_black>well, you can interrupt the syscall explicitly, that's thread_abort <rsmarples>well it can. if you look at the libpcap code I posted it was a small timeout where it calls pthread_testcancel() .... but that's not efficient <solid_black>which will make the other thread return from mach_msg with MACH_RCV_INTERRUPTED <solid_black>you should pass MACH_RCV_INTERRUPT, otherwise mach_msg implicitly retires after an abort <solid_black>but also, I'm not sure if that is the proper way, vs just sending yourself a message <rsmarples>will pthread_cancel transalte into thread_abort on hurd? <damo22>wont it return MACH_RCV_PORT_DIED ? <solid_black>oh, you mean that the main thread could destroy the receive port? and that would cause MACH_RCV_PORT_DIED in the other thread? <solid_black>of course one issue with all those things is that it races against the server actually replying <solid_black>the hurd has the intr-msg facility to do interruptions in a race-free manner <solid_black>where you tell the server "you know what, that request I sent you, nevermind", and then wait for the server to reply with either EINTR, or the actual response if it is ready <solid_black>it depends on server (and client) support for interrupting this specific sort of RPC <solid_black>support for this is indicated by the INTR_INTERFACE in a .defs <solid_black>so the question is, what is that mach_msg receiving in your case, what's the API / RPC <damo22>but if youre ending the transmission early, you dont care about the current packet arriving? <solid_black>it generally depends on the use-case, perhaps in this case you don't <damo22>rsmarples: that might give you some more ideas <rsmarples>moved all malloc memory to the context and cleanup when the thread exits <rsmarples>keeps it simple, avoids over engineering on mach specifics <rsmarples>the kernel BPF filter is too small for my ARP filter <Pellescours>youpi: I mean it hang, while it should return. In Glibc the test socket/tst-shutdown fails, the read call should return, and it actually hang. I spawned a modified pflocal to play with, and when doing a read call that return a 0 size (S_io_read return *data_len = 0), it hang instead of returning 0 <solid_black>they too say, "The 9P filesystem protocol relies on stateful file opens which map protocol-level FIDs to host file descriptors. The FreeBSD vnode interface doesn't really support this and we use heuristics to guess the right FID to use for file operations." <rsmarples>ok, i can safely skip the ARP hln check as ethernet is fixed size and we check it's ethernet in two places. I double check after packet collection anyway outside of BPF <rsmarples>alr, almost over the line now. who knows about PFINET and debugging it? <rsmarples>my last issue is that CMSG on received packets is totally bogus <rsmarples>with zero or one socket options I still get a cmsg with level and type of zero <rcttts>hello, any hardware recommendation for debian/hurd? <azeem>rcttts: most run it in a VM. If you want to run it on physical hardware, some not-so-recent ThinkPad is probably your best bet <rcttts>i see so smth like T400 or so would do the trick i guess <azeem>I think that's roughly the right ballpark, yeah <diegonc>I'm trapped in the rabit hole of the oasis virtio spec and don't know how to get out of it :P <diegonc>I guess I should learn how to use rump instead hehe <bjc>are the virtio drivers being packaged into rumpdisk now? <rsmarples>I'm interested in getting IN_PKTINFO working to fix the last real issue (other than the previously discussed header issues) in dhcpcd on hurd for pfinet <youpi>we already define IN_PKTINFO, don't we? <youpi>sysdeps/mach/hurd/bits/in.h:#define IP_PKTINFO 25 /* bool; Receive if/addr w/datagram*/ <rsmarples>but in the CMSG I get a bogus value - type and level are both zero <youpi>then there's probably some bug somewhere <youpi>but the question is not about the value of IP_PKTINFO :) <rsmarples>well, i need it to work out the incoming interface :) <youpi>possibly the pfinet's info structure doesn't match what is exposed in the glibc headers <rsmarples>what I don't want to do is add a __GNU__ block and assume we are pfinet and just have one working interface. <rsmarples>as i hope lwip supports more than one interface :) <rsmarples>(no idea, can't get it to run, job for another day) <youpi>rsmarples: you say type and level are zero, I assumed you were talking about fields in the pktinfo structure, but you mean the fields in cmsghdr, right? <youpi>so it's not a problem of pktinfo structure, but getting cmsg itself <youpi>and it's not actually related to IP_PKTINFO in particular, probably <youpi>or possibly the put_cmsg() call in pfinet's ip_cmsg_recv_pktinfo wrongly records information, for whatever reason <rsmarples>unsure if related but i can avoid setting any socket options and still get an unexpected cmsg entry <youpi>probably better check that put_cmsg inside pfinet is actually doing something <youpi>I see in pfinet/glue-include/linux/socket.h that if it doesn't have CMSG_DATA, it reduces to doing nothing <youpi>possibly we just don't get the CMSG_DATA definition there <youpi>or such kind of oddity, better just check <rsmarples>actually as I habve you here, what do you think about changing device/bpf.h bpf_insn to uint16_t, uint8_t, uint8_t, uint32_t like every other platform? <rsmarples>I'll start looking into the hurd sources then. grrrr, been trying to avoid that <rsmarples>I find BSD kernel code somewhat easy to follow, linux not so much <rsmarples>dhcpcd will stil work fine as is .... renewal will fail but rebind will succeed. <rsmarples>is there a gnu mach bug tracker or somewhere to submit patches? <sam_>rsmarples: ok call off The Boyz, looking at glibc now <rsmarples>alr, dhcpcd now compiles on gentoo/hurd with zero warnings (with a change to device/bpf.h I want to upstream)] <rsmarples>sam_: great! This is the last change I need before publishing some code to my repo I think <rsmarples>sam_: did you see my pfinet init.d script and changes to the runttys init.d script? can you handle those as well pretty plz :) <sam_>youpi: if you change your email on sourceware bz to sthibaul@sourceware.org you should get permissions to edit bugs <youpi>I already have permission to edit bugs :) <sam_>do you mind if i backport fixes for hurd to glibc branches where appropriate? generally only the latest one. it looks like it doesn't tend to happen (which is fine) but just checking if you mind that i do <sam_>e.g. here i've done the header fixes roy needs as they can't have worked before <youpi>you're welcome doing work :) <sam_>i figured that'd be the answer but i didn't want to step on toes <youpi>the branches that the few hurd distributions use would be the only useful ones indeed <sam_>rsmarples: will check out init scripts now <sam_>rsmarples: are you able to use glibc-2.43.9999 I committed for now until we roll the next patchset for glibc? <rsmarples>sam_: i have no idea. what do i need to do to get it? <sam_>rsmarples: in /etc/portage/package.accept_keywords (or if it's a dir: /etc/portage/package.accept_keywords/glibc or whatever name you want): =sys-libs/glibc-2.43.9999 ** <rsmarples>ok will do that when i get the dev box back. it's downloading overwatch 2 for my daughter to play tomorrow <rsmarples>sam_: do you know the best place to submit bugs/patches for gnumach? <sam_>it's really the general hurd ML for patches, bugs, and discussion <rsmarples>sam_: ok, hopefully ill get it in tomororws webrsync <rsmarples>great emerge glibc kills the hurd vm entirely <sam_>building glibc has been okay for me but maybe oom'd? <sam_>how much ram have you given it? <sam_>at worst i can always build a new image for you <sam_>(we don't yet have regular builds of the images, but we do have a script I can easily run for it) <rsmarples>sam_: i gave it 4GB and only 2 cpu. I've changed it to 3GB and 4 CPU as that aligns more with what x86 can do <rsmarples>but is crashed hard before it finished the git checkout ... <rsmarples>sam_: does portage remeber the git repos so it doens't have to fully sync all the time? <sam_>anyway it's ok, I'll figure something else out, but tomorrow <sam_>serves me right for trying to find a shortcut :) <sam_>rather than figuring out some solution that avoids that <rsmarples>maybe i gave it too much memory to handle - 4G is the limit of what i386 can do <sam_>thanks for your perseverance and work on all of this <rsmarples>the ethernet header thing is annoying me still, but i can't think of a good workaround <rsmarples>that's non invasive to either glibc or my code <sam_>i can try find time to look at that but it's not something i can say will be tomorrow either <sam_>need to dig up what previous review comments wer e if any, etc <sam_>maybe i could rebase it enough to add it to gentoo for now though <rsmarples>it was a big patch as it moved stuff around in glibc and it's ancient so likely doesn't apply anymore <sam_>also scares me a bit because if the big boss didn't feel comfortable applying it (albeit many years ago) then i wonder if i'll miss something :) <rsmarples>ah well, a few games and bed i think. enough for today <rsmarples>by locks up i mean my ssh is dead and the console just scrolls to a black screen on keypress <rsmarples>if i wasn;t pressig keys, top showed activity but not it wasn't doing much