On 15/09/14 15:02, David Herrmann wrote:
> Hi
>
> On Mon, Sep 15, 2014 at 3:19 PM, John Haxby <john.ha...@oracle.com> wrote:
>> On 12/09/14 16:03, Kay Sievers wrote:
>>> On Fri, Sep 12, 2014 at 3:04 PM, John Haxby <john.ha...@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
>
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
