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

[John Haxby]

On 15/09/14 15:02, David Herrmann wrote:
> Hi
> 
> On Mon, Sep 15, 2014 at 3:19 PM, John Haxby <john.haxby at oracle.com> wrote:
>> On 12/09/14 16:03, Kay Sievers wrote:
>>> On Fri, Sep 12, 2014 at 3:04 PM, John Haxby <john.haxby at oracle.com> wrote:
>>>> 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.
>>
>> That's what I don't understand.
>>
>> Let's say I plug in a USB printer.  Looking through the udev rules on my
>> machine I see
>>
>>     SUBSYSTEM=="printer", TAG+="systemd"
>>        ENV{SYSTEMD_WANTS}+="printer.target"
>>
>> (line split for readability).    A whileback I proposed
>>
>>    ACTION==“add” KERNEL==“cpu[0-9]*” TAG+="systemd"
>>        ENV{SYSTEMD_WANTS}+=“cpuadd.service”
>>
>> Aside from the obvious syntactic differences, what's the difference
>> between these?
> 
> One is a target, the other is a service. There is a fundamental
> difference between both. A target does not cause an immediate action,
> a service does. The target just hooks up the udev event into systemd,
> it does not associate any default action. The cpuadd.service, on the
> other hand, does add a default action.
> 
>> Does it make any difference if the default is not to bring online more
>> CPUs that the system booted with?  Or some other clever default?
>>
>> Why does the kernel not bring CPUs online automatically?  This must have
>> come up before, and what you have been saying seems to suggest that
>> there is something going on here that I am just missing.
> 
> The idea is to add a kernel runtime option (like sysctl) which is
> named "cpu_auto_on" or something like that. Or make it a sysfs file in
> /sys/bus/cpu/ just like "drivers_autoprobe". This should be set to "1"
> by default, thus, all CPUs get activated without any udev interaction
> (if you want to avoid races during bootup, use the kernel
> command-line.. or a static kernel config option..).
> Everybody else is free to set this option to "0" and write their own
> udev rules. This way, udev does not have to bother with default
> actions.
> 
> Is there anything wrong with this proposed solution? Or why do you
> insist on your solution?


Forgive me, I'm not insisting on anything.  It was me that that said
"hang on, we need to push that fix upstream" a while ago precisely to
ensure that we got the right solution for the right reasons.

I really appreciate proper explanations, thank you.



> 
> Thanks
> David
>