On Tue, Sep 2, 2014 at 10:01 AM, John Haxby <john.ha...@oracle.com> wrote:
>
> On 2 Sep 2014, at 06:55, Kay Sievers <k...@vrfy.org> wrote:
>
>> On Tue, Sep 2, 2014 at 5:22 AM, Zhenzhong Duan
>> <zhenzhong.d...@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.
Kay
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
