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

[Kay Sievers]

On Tue, Sep 2, 2014 at 5:29 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> On Tue, Sep 02, 2014 at 10:27:37AM +0200, Kay Sievers wrote:
>> On Tue, Sep 2, 2014 at 10:01 AM, John Haxby <john.haxby at oracle.com> wrote:
>> >
>> > On 2 Sep 2014, at 06:55, Kay Sievers <kay at vrfy.org> wrote:
>> >
>> >> On Tue, Sep 2, 2014 at 5:22 AM, Zhenzhong Duan
>> >> <zhenzhong.duan at oracle.com> wrote:
>> >>> Cpu doesn't get online automaticly after hotplug when we test guest cpu
>> >>> add/remove in xen env.
>> >>>
>> >>> I don't have an baremetal env to test this, but I think it's same.
>> >>>
>> >>> The rule is missed in systemd but exist in legacy udev.
>> >>
>> >> Udev is not a mechanism to establish an unconditional loop from the
>> >> kernel back to the kernel. Such rule makes no sense and we never
>> >> shipped that and will not ship it upstream now.
>> >>
>> >> If a device should be unconditionally change its state, the kernel
>> >> should just do that on its own, and not rely on userspace to do that.
>> >
>> >
>> > Kay,
>> >
>> > I’m curious.   Are you thinking of 40-redhat.rules in the RHEL6 udev as not being part of the legacy distribution?
>> >
>> > Should there be a rule that uses a systemd target to hot-add CPUs to provide the conditional aspect that’s needed?  Am I right in thinking that this is as simple as turning the old redhat rule into something like
>> >
>> > ACTION==“add” KERNEL==“cpu[0-9]*” TAG+=“systemd” ENV{SYSTEMD_WANTS}+=“cpuadd.service”
>> >
>> > And the corresponding service’s ExecStart is what actually puts the CPU on line?
>> >
>> > Sorry for the questions, I’m still trying to find the time to get to grips with systemd — that’s a poor excuse for something that’s been around for some considerable time I know, but be kind to me :)
>>
>> No, that is the same, just even more complicated. Establishing
>> unconditional loops from the kernel trough userspace back to the
>> kernel are wrong and pointless. If the CPU should always be onlined
>> with that event, please change the kernel to do that on its own, and
>> do not hook up userspace to do that.

> 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