Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel [LWN.net]

Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel

Posted Feb 12, 2013 11:12 UTC (Tue) by wahern (subscriber, #37304)
In reply to: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel by butlerm
Parent article: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel

PR stands for partially reliable, so you've just solved the problem by redefining "reliable" as "unreliable". (Which I guess is inevitable.) And in any event, if you want to parameterize expiration, on its face that's something you would think would be far preferable to implement in user-land, where it's easy to hack on and change with experimentation, instead of having to invent an interface to last all eternity. Obviously not much of an option for PR-SCTP, but open source software doesn't need to set a protocol in stone as long as the implementing library is free, open, and portable.

Also, PR-SCTP isn't multicast. The problem with reliable multicast is dealing with a single errant process complicating life for everyone else. Do you handle that complexity in kernel or user-land?

I don't really get the need for AF_BUS at all. Why not simply invent some sort of broadcast signaling system, similar to eventfd(2), but where bad processes can't drain the signal queue. Then just use a regular shared memory scheme for transfer. Now you've derived all the benefit without requiring the kernel to implement another idiotic kind of OOM killer in the kernel, and instead it can enforce hard limits and require user-land to cope. User land will be free to make the multicast channel as reliable or unreliable as it wishes.

(Log in to post comments)

Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel

Posted Feb 12, 2013 21:11 UTC (Tue) by butlerm (subscriber, #13312) [Link]

Unless you have an infinite amount of resources, all reliable multicast systems are partially reliable. The only question is when you resort to the expedient of dropping non-responsive recipients, dropping messages to non-responsive recipients, or blocking indefinitely.

I suspect the DBUS developers did not intend to set up an electronic mail system, but rather intended the service for messages only useful if they are delivered in a bounded time. DBUS doesn't preserve messages across reboots does it?

No sane kernel implementation of reliable multicast would either. It seems pretty obvious that you must either kick out or drop messages to non-responsive recipients, with some appropriate definition of non-responsiveness, or you can't do anything useful. Blocking the sender is not a realistic option.

There is no need to kill any processes - each receiver should have a receive buffer limit, and be sent a control message when one or more messages were dropped because that limit would be exceeded.