On Wed, Dec 5, 2018 at 8:45 PM David Miller <da...@davemloft.net> wrote: > > From: Jouke Witteveen <j.wittev...@gmail.com> > Date: Wed, 5 Dec 2018 14:50:31 +0100 > > > For example, I maintain a network manager that delegates the actual > > networking work to specialized programs. > > Basically "I've implemented things using separate programs"
I was trying to give an example of a typical system administrator task. > > 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. > > And "In order to use rtnetlink I'll need a separate program!" > > (╯°□°）╯︵ ┻━┻ > > So it's ok to use the separate program paradigm for dividing up > the tasks, but not for processing events? > > I'm not convinced. This is about automation. When you want to take some action in response to an event, you want the event system to be accommodating. In that sense, it is indeed more ok for actions to require separate programs than for event listening. > Either use the facility we have or extend it to fill a valid missing > need. > > I'm not applying these patches, your logic doesn't add up and it's > inconsistent with our clear goals of not duplicating functionality. Can you elaborate a bit? I may not be aware of the policy you have in mind. Furthermore, I fail to see how these "change" events in response to link state changes are not to be expected. To me, it looks like uevents are there precisely to inform userspace about this kind of changes. As I asked in my conceptual argument, please consider this patch an extension of uevent coverage, more than an attack on rtnetlink (which it is definitely not). Regards, - Jouke
