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

[Kay Sievers]

On Fri, Sep 12, 2014 at 3:04 PM, John Haxby <john.haxby at oracle.com> wrote:
> On 02/09/14 16:42, Kay Sievers wrote:
>>> > Either the kernel has to provide a mechanism for the userspace to
>>> > control onlining, or do it itself and provide a mechanism to prevent
>>> > automatic onlining. I think that the first option is actually
>>> > cleaner. So yeah, let's add the original rule which does it
>>> > unconditionally,
>> No, as outlined already, we are not doing this. It is just wrong.
>>
>>> > and people who have too many cpus and have special
>>> > needs can provide a custom udev rule which does something different.
>>> >
>>> > cpuadd.service or cpuadd at .service seem overkill, since the one we
>>> > would provide would still do the exact same thing: unconditionally
>>> > enable the CPU.
>> Nothing wrong with that, if people need that. But this can for sure
>> not live in systemd/udev, it is not the right place.
>
> Kay, I've worked on a case with Xen domUs which have only some of their
> virtual CPUs online at any given time. This deployment has scripts which
> only turn up extra CPUs when one of the applications has to do a
> failover from one virtual machine to another. The point is that needed
> CPU hotplug behaviour is not necessarily uniform to everyone.
>
> Even if the default, out of the box, behaviour is to turn up the CPUs
> unconditionally, udev seems the best place to change this behaviour at
> runtime. The fact that CPUs can be hotplugged at all should imply that
> some users will need different behaviour than others. 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.

> 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.

> When I think of changing the
> behaviour of any removable hardware, udev is automatically where I look
> first. So if I'm missing something here, I would really like some more
> input.

Udev does not decide which device show up, it just classifies stuff
that processes events.

Kay