How did this guy test systemd exactly?

Posted Oct 13, 2010 13:12 UTC (Wed) by paulj (subscriber, #341)
In reply to: How did this guy test systemd exactly? by mezcalero
Parent article: Jaeger: systemd - and #osc2010

Oh, some specific, potential candidates:

- raw sockets
- meta-stuff like IP_PKTINFO, SO_BINDTODEVICE
- multicast stuff, IP_MULTICAST_LOOP, IP_ADD_MEMBERSHIP, IP_MULTICAST_TTL

To be clear, I think it'd probably be ungood for systemd to try explicitly support every possible socket type and option that services might want to use. ;) I'd prefer a coded offload mechanism.

How did this guy test systemd exactly?

Posted Oct 13, 2010 15:06 UTC (Wed) by mezcalero (subscriber, #45103) [Link] (1 responses)

SO_BINDTODEVICE we actually support (and actually in a pretty nice way, so that implicit deps on the network device are created, so that this actually works race-freely).

By "raw" sockets you mean raw IP sockets? Raw IP sockets usually also mean installation of a BSD socket filter, and I am not sure I want to include something like that in systemd.

AFAIK IP_PKTINFO is something that can be set when the app first takes possession of the socket. There's no need to set it before listening.

Apple's launchd has multicast support. I'd be willing to add that to systemd too, but I wanted to wait for a real-life usecase. Avahi (which I maintain) is probably the heaviest user of mcast on default Linux installations right now, and I don't think for Avahi it would make sense to have this.

How did this guy test systemd exactly?

Posted Oct 13, 2010 16:02 UTC (Wed) by paulj (subscriber, #341) [Link]

You can bind raw sockets to a specific IP protocol, and/or multicast groups. So you don't need a BPF filter per se. I'd have to read the kernel code for PKTINFO, but it wouldn't surprise me if the kernel marshalled the ancillary meta-data for the packet at the point of copying it into the socket buffer - and that it might not be available if you set PKTINFO later. I don't know though, havn't checked. ;)

Anyway, the point is, we shouldn't need this conversation - it'd be nice if apps could take care of the weirder stuff themselves by supplying their own binary to do the setup. ;)

Use cases: certain link-info and routing protocols. E.g. imagine you plug into a network that sends default route info via some routing protocol. Rare case, but imagine if systemd could auto-launch the right daemon.. Link-info protocols can clues about location and the like.