Am Dienstag, 18. September 2001 18:06 schrieben Sie:
> > but a patch to add a flag to the usb core and the host controller drivers
> > is still needed. I'll have a look at it. I propose the flag to be called
> > URB_MEM_NOIO.
>
> As I understand it, that sounds appropriate. Basically, any place that
> usbcore or an hcd now uses GFP_KERNEL, if URB_MEM_NOIO
> is set then it should use GFP_NOIO instead. Similarly for using
> SLAB_KERNEL and SLAB_NOIO.
Yes.
> The pci_pool calls will need a tweak; they test for SLAB_KERNEL,
> but SLAB_NOIO should work there too.
Explain please.
> Some USB APIs will be trouble, since they don't pass an URB
> or explicit mem_flags value down. Were you thinking of just
> making it all use SLAB_NOIO? That might cause a few more
These are usb_control_message() and usb_clear_halt(). I was thinking
of doing a version for block devices that uses NOIO. Thus compatibility is
maintained in 2.4 and in 2.5 we'd merge and add another parameter to the
call.
> "out of memory" error reports in places it's not necessary (khubd
> as one example). But I'm not sure making usb_control_msg() and
> all its callers (and their callers ... :) take a new mem_flags parameter
> would be a reasonable API change.
Which leads to the question whether another parameter to usb_submit_urb()
would be acceptable, too. We could get rid of the in_interrupt() checks in
the host controler drivers, too.
Still we still deadlock if GFP_NOIO fails in swapping. We need a small pool
of free pages which GFP_NOIO will be serviced from and GFP_ATOMIC won't be
serviced from.
Regards
Oliver
-------------------------------------------------------
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
