IRC channel logs

<rrq>would possibly someone help me with getting a working tap device going in hurd

<etno>rrq: as I understand it, TAP devices are a monolithic kernel kludge. They exist because network devices are kernel objects.

<etno>In the Hurd, I think that one would just implement a network device in their process

<etno>The Ethernet multiplexer is most probably an example of such implementation.

<youpi>pfinet already has integrated support for it

<youpi>that's simpler than writing a separate translator

<rrq>I have not managed to use pfinet for ethernet packet send/recv

<youpi>I mean pfinet has support for tun, and adapting it to tap is a matter of stuffing/unstuffing the ethernet header

<etno>Oh, so there is a compatibility layer to port programs using linux TAP. Is this correct, youpi ?

<youpi>try to make the tun support for a start

<youpi>and then it'll be simpler to see how to fix it into supporting tap

<youpi>etno: no compatibility layer needed, it's just a matter of adding/removing the ethernet header when configured as tap instead of tun

<youpi>it's very OS-independent

<etno>I mean, this support is taylored for porting applications using a tun/tap subsystem

<youpi>yes

<youpi>(though for now it only supports tun)

<rrq>well the tap support is yet to be completed

<etno>Thanks for the clarification

<youpi>yes, but the tun support is 98% of the work

<youpi>the remaining 2% is really simple once understood how things work

<rrq>I have tried it once, but those 2% are a pretty big hurdle for me :)

<etno>I would be mostly worried with how the application will handle the routing configuration after the device itself is obtained 😅 (since we are talking about portability)

<youpi>rrq: did you see how the tun support is implemented?

<rrq>I've read the source yes

<youpi>etno: that's not really different between tun and tap

<etno>Yes, youpi, I am considering the benefits of tun/tap support overall

<youpi>rrq: the different would really lie essentially in setup_tunnel_device to determine whether /dev/tunx or /dev/tapx was given, to switch between the two behaviors

<youpi>and then in trivfs_S_io_read and trivfs_S_io_write to add/remove the ethernet header

<youpi>and that'll be it

<rrq>mmm classify it as ETH_P_LOOP I suppose?

<youpi>no, you read it from the header

<rrq>ok so need to handle vlan tagging..

<youpi>start without caring about vlans

<youpi>always start simple

<youpi>and make things complex later

<rrq>ok seems clear. another minor detail: the dev mtu, type and flags need to be slightly different

<rrq>but that might be all

<Darelelve>youpi: Hello, I submitted several patches a few days ago, but I still haven't received a response. Perhaps I did something wrong? If it takes longer to respond, I apologize for the inconvenience...

<youpi>what were they about?

<Darelelve>Added checks for alloc return value in several place and [PATCH] Migrating storeio from trivfs to netfs

<youpi>they are still in my inbox :)

<Darelelve>Ah, ok

IRC channel logs

2026-07-21.log