On Thu, 13 Sep 2007, Adrian Bunk wrote:Your meaning isn't entirely clear. Presumably HAL will contain such a whitelist. But there's nothing to stop you from setting up your own whitelist via udev scripts, or even turning autosuspend on or off by hand. It's not clear that this sort of approach will turn out to be workable. Whitelists/blacklists do okay in the kernel when they refer to a relatively small subset of devices. However in this case I have the impression that we're talking about roughly a 50/50 split. Keeping an in-kernel list with even 10% of all existing USB devices simply isn't feasible. Besides, is it really that much harder for userspace to modify device settings as the devices are detected than for it to modify an in-kernel whitelist just once? Don't forget about possible races: Devices may already have been detected and configured before userspace was able to modify the whitelist. Alan Stern -
| Steven Rostedt | Re: Major regression on hackbench with SLUB |
| Jeremy Fitzhardinge | [PATCH 02 of 36] x86: add memory clobber to save/loadsegment |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Paul Jackson | Re: cpuset-remove-sched-domain-hooks-from-cpusets |
git: | |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Arjan van de Ven | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Jarek Poplawski | [PATCH iproute2] Re: HTB accuracy for high speed |
