Re: [PATCH 1/2] net: linkwatch: send change uevent on link changes

On Wed, Dec 5, 2018 at 8:45 PM David Miller [off-list ref] wrote:

From: Jouke Witteveen <redacted>
Date: Wed, 5 Dec 2018 14:50:31 +0100

quoted

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.

quoted

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