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

[Kay Sievers]

On Tue, Sep 2, 2014 at 5:30 PM, John Haxby <john.haxby at oracle.com> wrote:
> On 02/09/14 16:23, Kay Sievers wrote:
>> On Tue, Sep 2, 2014 at 5:11 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>>>
>>> John Haxby wrote on 02/09/14 10:31:
>>>> Col, forgive my ignorance, but cpuadd@$name.service seems to imply that
>>>> you'd have one file or symlink per CPU.  That's going to be unwieldy
>>>> when you have hundreds of CPUs isn't it?
>>>
>>> Not quite. systemd units with an @ in them are a bit special. You have
>>> one unit file on disk (cpuadd at .service) and you can instantiate
>>> instances of them via cpuadd at xxx.service where the value xxx is
>>> available inside the unit and can be passed to scripts or binaries in
>>> the ExecStart lines via the %i and %I modifiers.
>>>
>>> In this case you wouldn't ever enable them individually via explicit
>>> symlinks (which is valid in some use cases) but udev would defer to
>>> systemd to start the instance as needed. This is very similar to how the
>>> built in systemd-rfkill at .service works. See
>>> /usr/lib/systemd/system/systemd-rfkill at .service. It's instantiated as
>>> systemd-rfkill at rfkill1.service for example.
>>>
>>>
>>> It's basically the way to pass in the the CPU number or name to the
>>> service so you can implement that mission critical "only allowing prime
>>> numbered CPUs on Wednesday" policy ;)
>>
>> Nice description. :)
>>
>> But just in case someone thinks of any per-CPU onlining policy
>> machinery now: We will not ship anything in that area in systemd/udev
>> upstream. This stuff just belongs into the kernel, like it works for
>> any other device.
>
> Do you mean that the kernel should not be generating udev events for cpu
> hotplug?

Sure, nothing wrong with these events.

> Or that there is some other mechanism that the kernel should
> be using to allow cpu hotplug policy to be decided by userland?

It should not be decided by userland. And as the proposed rules show,
nobody needed that so far, and we are not making up theoretical use
cases here now, just as an argument for the userspace even echo.

If things should be onlined when they show up, the kernel should just
do that itself. There is no point in looping anything like that by
default through userspace. It is the same as automatic driver-binding,
it can (nobody does that) be disabled and taken-over by userspace, but
the default is just in the kernel where it belongs.

Kay