On Mon, Apr 20, 2015 at 8:11 PM, David Herrmann <dh.herrm...@gmail.com> wrote: > Hi > > On Sun, Apr 19, 2015 at 11:46 PM, Matthew Garrett <mj...@srcf.ucam.org> wrote: >> On Sun, Apr 19, 2015 at 11:37:31PM +0200, Kay Sievers wrote: >>> 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? > > I'd much prefer if this was hwdb based. This way, we have a sane > database that just sets something like POWER_CONTROL=foobar, which we > can then apply via udev. Given that the power-control issues seem to > be totally random, hwdb really sounds like the nicer solution. > > Any reason why hwdb would not work?
The question here is more why systemd/udev should get into the power management business at all. So far, applying unconditional policy sounds like a job for the kernel, not userspace. Either it can be safely ensabled, then it can be done right away by the kernel driver, or it isn't safe, then using udev does not solve any problem. Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel