lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 03 Aug 2007 14:26:43 +0200 From: Rogan Dawes <lists@...es.za.net> To: Matthew Garrett <mjg59@...f.ucam.org> Cc: Oliver Neukum <oliver@...kum.org>, David Brownell <david-b@...bell.net>, Greg KH <gregkh@...e.de>, Alan Stern <stern@...land.harvard.edu>, linux-usb-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org Subject: Re: [PATCH] USB: Only enable autosuspend by default on certain device classes Matthew Garrett wrote: > On Fri, Aug 03, 2007 at 01:44:02PM +0200, Oliver Neukum wrote: >> Am Freitag 03 August 2007 schrieb Matthew Garrett: >>> It's certainly possible to do that, but it's also possible to have a >>> userspace solution that whitelists devices. The question is whether the >>> default kernel behaviour should be "Save power, but potentially break >>> some of my devices" or "Don't break my devices, but use some more >>> powre". >> If both options have drawbacks, IMHO we follow the standard, which >> says that devices must support suspension. > > Except that lots of hardware doesn't follow the standard in this > respect, otherwise we wouldn't be having this discussion. Personally, I > think "Will break an unknown number of devices" is a significantly > larger drawback than "Will consume a small quantity of additional > power". > I guess the question could be phrased: Which one is more likely to conclude at some point? That is, if we blacklist by default, we consume that additional power indefinitely, because it is unlikely that people will report "my machine uses 200mW more than I think it should", and thus we are unlikely to build up knowledge of exactly which devices/classes should be blacklisted. Compare that to: "My USB printer broke, guess I'd better report it to LKML". The first option is unlikely to ever reach a satisfactory conclusion, whereas the second one is quite likely to flush out the guilty parties within a relatively short time. FWIW. Rogan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists