Re: New USB stack on FreeBSD w/Linux emulation layer coming

On Wed, 16 May 2007, David Brownell wrote:

> > I have never, ever, seen USB stack deplete the atomic pool completely
> > either, if this is what you are talking about. So, you're quite right
> > about that.
> 
> I was referring to the dma_pool allocations ... those don't need
> to be atomic.  OHCI or EHCI tend to allocate a page or so for each
> type of descriptor seen by the hardware, and usually won't need
> more than that.  UHCI uses more pages; TD-per-packet requirements
> from the hardware, ISTR (instead of multiple-pages-per-TD).

If dma_pool allocation isn't atomic, does that mean it could block for 
I/O?  If yes, then it doesn't belong on the usb-storage I/O path.

> > I have come to think that ub does not dramatically alter the pressure
> > on the atomic pool. It allocates the same QHs and TDs. It's the thread
> > which is the main problem, because it allows for interesting scenarios
> > of deadlocks between kswapd, scsi_eh_0, and usb-storage helper.
> > I am thinking about taking the ub concept and integrating it into
> > usb-storage as some kind of "threadless" option. If only I could
> > get rid of the SCSI error handling...
> 
> Agreed, all those threads make things complex ... probably more so than
> is really needed.

I wonder...  ub does away with thread complexity by using a complex 
state machine.  Ultimately the complexity lies in the USB mass-storage 
protocol and in error handling; we can't get away from it no matter how 
we try.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel