On Wednesday 13 March 2002 22:49, Greg KH wrote:
> On Tue, Mar 12, 2002 at 11:30:06PM +0100, Oliver Neukum wrote:
> > On Tuesday 12 March 2002 21:37, Greg KH wrote:
> > > On Tue, Mar 12, 2002 at 06:26:01PM +0100, Oliver Neukum wrote:
> > > > Ok, Greg, you'll kill me for this, but usb_submit_urb needs a further
> > > > parameter describing a data structure with a pointer to a memmpool
> > > > and ownership of that pool.
> > >
> > > Bleah :)
> > >
> > > Are you sure this is needed?  I think the host controller drivers can
> > > handle this properly on their own, by always using a mempool in the
> > > first place.  I don't want to burden _every_ usb driver with having to
> > > create such a mempool, when it is the host controller that is the one
> > > that really needs it.
> >
> > Well, it need not be a burden. If a driver doesn't care, let it submit
> > NULL.
>
> And then what will happen?  The host controller will have to use it's
> private mempool?  Why not just have the host controller use it's private
> mempool _all_ the time, which would not cause any driver changes.

If the driver supplies no mempool and OOM occurs the urb fails.

The problem is that a mempool can serve only a limited number of urbs
and still guarantee memory. Usually a mempool is wasted memory.
Thus the reasonable size for the mempool is large enough for one
urb under the worst circumstances. Thus we need mutual exclusion.
And it has to be explicit, as the HCD cannot know which urb is
important.

        Regards
                Oliver

_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to