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. Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
