On Sun, Apr 19, 2015 at 11:37:31PM +0200, Kay Sievers wrote: > On Sat, Apr 18, 2015 at 9:39 PM, Matthew Garrett <[email protected]> wrote: > > 1) having this in udev makes it easier for users to alter the > > configuration - the kernel can then afford to be conservative until we > > enable power management, rather than potentially breaking the device the > > moment pm is enabled without any ability to recover it. > > There is no significant difference between a default unconditional > udev setting and a kernel command line option to control such behavior > if needed.
The command line option would need to be per-device, so I can't see a terribly good way to express that. > > 2) this config is currently static, but the appropriate policy may turn > > out to be more complicated in some scenarios (interactions between > > devices and their upstream bridges, for instance, or USB Bluetooth > > controllers that are on-die with a PCI wifi controller without having a > > common exposed bus topology yet still having pm interactions). Splitting > > this between udev and the kernel makes it more difficult to determine > > the source of the policy and debug it. > > Either the setting is safe to use or not, the source of this policy is > not really relevant here. The loop through userspace does not sound > useful. There's no mechanism in the kernel to say "Enable power management on this USB device only if a specific PCI device doesn't exist". This kind of policy is much easier to express in userspace than in the kernel. > > 3) we already have examples of this in udev, so people already expect to > > find it here. > > Which should be a reason to carefully check these examples if they > should stay in udev, not a reason to justify to add more. Well, that's certainly an option. > I'm not convinced that any such broad matches for power management > belong into udev at all. Udev can carry specific device matches, or > carry data that cannot be determined from the device itself, like the > mouse resolution and such, but like in these rules, reading the vendor > from the kernel and unconditionally flipping a bit back into the > kernel does not look like a task for udev or userspace in general. Is there any possibility that you can be convinced? -- Matthew Garrett | [email protected] _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
