On Wed, 9 May 2007 11:16:06 +0200, Duncan Sands <[EMAIL PROTECTED]> wrote:
> The main difficulties encountered with usbatm were: (1) avoiding race > conditions on device disconnect; (2) providing a way to cancel heavy_init. > As mentioned in my original email, heavy_init could run forever depending > on how the system is configured. In the current implementation a signal > is sent on disconnect(), to indicate that the game is up, then disconnect() > blocks until heavy_init terminates, if it hasn't already. A better method > would be to allow registration of a cancel() routine, which disconnect > would call before blocking on heavy_init termination. This could send a > signal, or complete a completion, or whatever. Yes, a cancel routine would make sense also in the generic probe()/setup() case. > Sadly, the generic firmware > loading infrastructure doesn't have a way of asynchronously cancelling a > firmware load, so right now cancellation only does something if the firmware > has already been loaded from disk, in which case it cancels the upload to the > modem (which is the most time consuming part). Hm, a firmware load cancellation interface looks like a worthwile addition to the firmware code (especially since fw_load_abort() already exists and can even be triggered by userspace). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
