On 02/09/14 16:23, Kay Sievers wrote: > On Tue, Sep 2, 2014 at 5:11 PM, Colin Guthrie <gm...@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@.service) and you can instantiate >> instances of them via cpuadd@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@.service works. See >> /usr/lib/systemd/system/systemd-rfkill@.service. It's instantiated as >> systemd-rfkill@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? Or that there is some other mechanism that the kernel should be using to allow cpu hotplug policy to be decided by userland? > Kay > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
