On Sun, Feb 03, 2002 at 09:20:10AM +0100, Oliver Neukum wrote:
>
> > For this case, I'd argue that a driver shouldn't be allocating a urb
> > within an interrupt at all :)
>
> In this case that can be done. But it's not an answer to all such problems.
Why not? Are there other times we need to allocate an urb in this
manner (where we can't call schedule())?
> > Now the comments about the HCD drivers needing to know about this, and
> > their API being changed, I understand. I'd be glad to accept such a
> > patch (I am even willing to fix up all of the drivers in the tree, if
> > someone wants to just patch the HCD drivers, and a single device driver
> > to test things with.)
> >
> > And no, I don't mind breaking API compatibility between 2.4 and 2.5 trees
> > to fix such a real problem. After 2.5 is changed, and problems are
> > shaken out, we can always backport to 2.4, if necessary.
>
> If you want this shouldn't we make a clean break and change names ?
No, just change the api (adding "int gfp" to usb_submit_urb()) and fix
everything up. I don't want to add more functions. Hey, _I_ just
offered to fix up all of the drivers, please take me up on this :)
This is one of the joys of Linux development, we don't have to keep old
interfaces around, and be forced to create new ones. We can fix the old
one correctly, like this would do:
int usb_submit_urb (struct urb *urb, int gfp);
> int usb_revoke_urb_sync(struct urb *urb);
> int usb_revoke_urb_async(struct urb *urb);
Are you trying to split up the current usb_unlink_urb() case? Do you
think this is really necessary?
> void usb_wait_completion(struct urb *urb);
I like this. It would probably clean up a lot of driver code, right?
thanks,
greg k-h
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
