On 27 May 2007, at 21:31, Rafael J. Wysocki wrote:I don't like this approach, as I feel that the firmware loading interface should be able to detect if a firmware load request is not being handled, due to absence of userspace / hotplug handler presence. Other circumstances in which this can be a problem is during bootup when request_firmware() calls can be made before userspace is up and init has run (even in the presence of an initramfs). (Slightly OT: A particularly nasty race is when an initramfs userspace is present, but firmware loading cannot occur because init has not run, so proc hasn't been mounted, so a hotplug event handler cannot be registered, despite the fact that the firmware is sitting on the ramdisk mounted correctly...) In short, a more general solution would be preferred, and preferably one which allows firmware loading to *actually* occur once userspace has actually turned up and registered a handler :) Michael-Luke Jones -
| david | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Heiko Carstens | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
git: | |
| David Miller | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 05/37] dccp: Cleanup routines for feature negotiation |
| Lennert Buytenhek | [PATCH 16/39] mv643xx_eth: get rid of ETH_/ethernet_/eth_ prefixes |
