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 -
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 014/196] kobject: remove incorrect comment in kobject_rename |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Stephen Rothwell | Re: Announce: Linux-next (Or Andrew's dream :-)) |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Radu Rendec | htb parallelism on multi-core platforms |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
