IRC channel logs

<azert>damo22: been reading about bpf. It seems to me that the Hurd already speaks that language https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/pfinet/ethernet.c#n365 or am I wrong?

<azert>damo22: https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/include/device/bpf.h

<damo22>yeah but BSD bpf is a /dev node that you can explicitly connect to

<damo22>in hurd its a lib

<damo22>we need the node version because it connects to rump kernel

<damo22>to access the net dev

<azert>Ok, but it seems to me that the Hurd was once speaking the bpf language to its network driver

<azert> https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/include/device/device.defs#n136

<azert>if you can resurrect that code, I think you’ll restore what was meant to be

<damo22>most likely yes, but we have resurrected it in the machdev

<azert>Because many pfinet can install their own bpf filters in the rumpnet

<azert>Yes

<damo22>we dont need the gnumach device

<damo22>gnumach doesnt need to serve the network device anymore

<azert>I agree I would ditch that

<damo22>libmachdev does this in userspace now

<azert>Yes, but you can resurrect the bpf part

<damo22>yes

<damo22>i left it as a commented out part in my code

<damo22>device_set_filter

<damo22> https://git.zammit.org/hurd-sv.git/diff/rumpnet/net-rump.c?h=rumpnet&id=48aa8fa7bf4252f39860c9a7c620c733d49ea26d see device_set_filter

<damo22>i need to rewrite the socket to use bpf though

<azert>Yes I see

<damo22>we might be able to have predefined bpf filters for tcp and udp packets, etc

<damo22>i really need to implement mach_printf()

<damo22>instead of mach_print()

<ZhaoM>youpi: do I need to submit the patch to util-linux when I get a working hwclock for Hurd?

<youpi>ZhaoM: probably better send it to bug-hurd first so we can check what it looks like

<ZhaoM>ok

<damo22>errr, send_packet and receive_packet in bpf.c requires knowing the MAC address of the destination and the IP address of the destination...

<youpi>for sending you know that, from the packet and from arp

<solid_black>hi

<youpi>for receiving, you should be able to request all packets

<damo22> https://github.com/NetBSD/src/blob/trunk/external/mpl/dhcp/dist/common/bpf.c#L403

<damo22>hmm ok

<damo22>cant seem to rump_sys_open(/dev/bpf)

<damo22>rumpdev_bpf

<damo22>we are missing a lib

<Pellescours>youpi: i think I found a potential deadlock (my hang from yesterday)

<youpi>oh, nice :)

<Pellescours> https://github.com/flavioc/gnumach/blob/master/vm/vm_page.c#L1039 this was the loop were my kernel hang

<Pellescours>object comes from vm_seg_pull_cache_page, and doc saus that when it returns, object is locked when shuccessfull call

<Pellescours>so we try to lock an object that is already locked. I din't see a unlock call between the 2

<youpi>that looks so indeed

<Pellescours>is an assertion to check that object is not lock here https://github.com/flavioc/gnumach/blob/master/vm/vm_page.c#L997 relevant ?

<youpi>you can try to check that for a start yes

<youpi>that being said, is vm_object_lock() not a nop in non-smp ?

<Pellescours>I compiled with smp enabled

<Pellescours>but running with 1 cpu

<Pellescours>is there a method to check a lock status?

<Pellescours>ah found

<Pellescours>yes, I think in non smp, vm_object lock is a no op

<Pellescours>vm_lock calls simple_lock

<youpi>ok, that can explain why we hadn't noticed it

<Pellescours>Doing a ctrl+alt+suppr in the hurd console (to reboot) make it crash

<damo22>Pellescours: i think i added a commit for fixing ctrl-alt-delete crashing the console

<damo22>but it may have exposed another bug

<Pellescours>should pae work with gnumach kernel drivers? I just tried it and I got a page fault

<ZhaoM>youpi: I asked a question about the util-linux hwclock patch but I forgot to set the "reply to" to you, please have a look when you have time

<ZhaoM>youpi: on the mail list

<Pellescours>for the console, I think the problem is here for long time.

<youpi>yes it was there, but got fixed, just waits for a new snapshot

IRC channel logs

2024-12-02.log