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

[Zbigniew Jędrzejewski-Szmek]

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

Zbyszek