[systemd-devel] [PATCH] Add the CPU hotplug rule

[Todd Vierling]

On Fri, Sep 12, 2014 at 11:03 AM, Kay Sievers <kay at vrfy.org> wrote:
>> Here, the default
>> action is almost a trivial configuration... but not the only possible
>> desired configuration.
>>
>> Can I ask your reasoning for CPU hotplug behaviour not being the role of
>> udev to fulfill? If that's not the right place, where do you believe
>> would be the appropriate alternative?
>
> As explained several times, there is no point in mis-using udev to
> unconditionally react to kernel events to trigger things in the kernel
> again. That is not how driver/device binding works for all the other
> subsystems on Linux.

We can now rename network interfaces based on their MACs upon attach
without involving the kernel? And reconfiguring a loaded kdump image
upon memory change no longer requires doing anything in the kernel? I
must have missed a piece of documentation somewhere.

I also didn't realize that having a configurable action made something
"unconditional". I thought that "unconditional" was in direct
opposition to "configurable". I need a new technical dictionary to
help me understand these new terms.

If it isn't clear, those statements have a liberal coating of sarcasm
to drive the points home.


>> I'm hoping you have another place in mind.
>
> The kernel itself or any other custom facility. This stuff has no
> place in default/upstream udev, it is the wrong way to do things in
> default setups.

udev processes kernel events in a programmatic fashion. That has
always been its purpose, stated in a single sentence, without
exceptions. There has never been some sort of holistic mission for
udev with a spiritual direction on the "way to do things". udev
processes events and allows configurable actions to handle them, full
stop.

What we do with those events is udev's rule configuration. Some of
those actions do involve telling the kernel to do something in
addition to the original event; see the two examples above (though
these are not the only ones in common use, obviously). If there were
no need to configure differing reactions to kernel events, rules.d
wouldn't exist.

All that is being proposed here is to offer a default reaction to a
CPU add event -- the configuration for which can be changed by a
system administrator, distro, or tool just by changing a text file,
rather than recompiling a kernel.

Making the action configurable, by definition, means that it is *not*
unconditional.

-- 
-- Todd Vierling <tv at duh.org> <tv at pobox.com>