On Wed, Dec 5, 2018 at 5:50 AM David Miller <da...@davemloft.net> wrote: > > From: Jouke Witteveen <j.wittev...@gmail.com> > Date: Sat, 1 Dec 2018 17:00:21 +0100 > > > Make it easy for userspace to respond to acquisition/loss of carrier. > > The uevent is picked up by udev and, on systems with systemd, the > > device unit of the interface announces a configuration reload. > > > > Signed-off-by: Jouke Witteveen <j.wittev...@gmail.com> > > --- > > I did not want to change the commit message into a systemd-howto, but > > subscribing to udev events can be done through a line like > > ReloadPropagatedFrom=sys-subsystem-net-devices-%i.device > > in a systemd unit file. > > I want to hear more about "why".
Let me give a conceptual and a practical reason. Conceptual. >From the net-subsystem point of view, it may not be clear why we should add uevents. However, from the uevent point of view, it is odd that networking devices do not send out "change" events when their medium (=link) state changes. For consistency, it would be better to also send out uevents. I would go as far as to say that uevents should have been used from the start, but they were not yet available back then (I believe rtnetlink predates uevents by at least five years). A good summary of this argument in favor of the patch is given by Stephen Hemminger: it makes sense. > If we have the rtnetlink message that can be listened for, userspace > ought to use that. That's what it is there for. Practical. If userspace refers to programs with fewer privileges than the kernel, than, indeed, it is not hard to set up a listener for rtnetlink messages in C. However, if it refers to system administration, then uevents are far more convenient to listen to, since they are propagated by udev and its likes. For example, I maintain a network manager that delegates the actual networking work to specialized programs. Basically, it is an implementation of network manager logic in shell script. For such a shell script, it is easy to respond to uevents (via udev, or alternatives), but responding to rtnetlink messages would require a separate program. The way I see it is that rtnetlink and uevents represent two different views of the system and link state changes should be visible in both. Regards, - Jouke
