On Tue, Sep 2, 2014 at 5:29 PM, Zbigniew Jędrzejewski-Szmek
<zbys...@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.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.
> 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@.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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
