On Fri, Sep 12, 2014 at 3:04 PM, John Haxby <john.ha...@oracle.com> wrote: > On 02/09/14 16:42, Kay Sievers wrote: >>> > Either the kernel has to provide a mechanism for the userspace to >>> > control onlining, or do it itself and provide a mechanism to prevent >>> > automatic onlining. I think that the first option is actually >>> > cleaner. So yeah, let's add the original rule which does it >>> > unconditionally, >> No, as outlined already, we are not doing this. It is just wrong. >> >>> > and people who have too many cpus and have special >>> > needs can provide a custom udev rule which does something different. >>> > >>> > cpuadd.service or cpuadd@.service seem overkill, since the one we >>> > would provide would still do the exact same thing: unconditionally >>> > enable the CPU. >> Nothing wrong with that, if people need that. But this can for sure >> not live in systemd/udev, it is not the right place. > > Kay, I've worked on a case with Xen domUs which have only some of their > virtual CPUs online at any given time. This deployment has scripts which > only turn up extra CPUs when one of the applications has to do a > failover from one virtual machine to another. The point is that needed > CPU hotplug behaviour is not necessarily uniform to everyone. > > Even if the default, out of the box, behaviour is to turn up the CPUs > unconditionally, udev seems the best place to change this behaviour at > runtime. The fact that CPUs can be hotplugged at all should imply that > some users will need different behaviour than others. Here, the default > action is almost a trivial configuration... but not the only possible > desired configuration. > > Can I ask your reasoning for CPU hotplug behaviour not being the role of > udev to fulfill? If that's not the right place, where do you believe > would be the appropriate alternative?
As explained several times, there is no point in mis-using udev to unconditionally react to kernel events to trigger things in the kernel again. That is not how driver/device binding works for all the other subsystems on Linux. > I'm hoping you have another place in mind. The kernel itself or any other custom facility. This stuff has no place in default/upstream udev, it is the wrong way to do things in default setups. > 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. Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel