On Wed, 7 Jul 2004, Bernd Walter wrote: > On Wed, Jul 07, 2004 at 11:16:14AM +0200, Poul-Henning Kamp wrote: > > In message <20040707091311.GE12877_at_cicely12.cicely.de>, Bernd Walter writes: > > >On Tue, Jul 06, 2004 at 04:32:28PM -0700, Julian Elischer wrote: > > > > >What about those options: > > >- limit the allocated memory to the user request so we don't take the > > > whole 128k if not reuired. > > >- Do interleaving with 2 or more xfers if the read request is known to > > > take more xfers. > > > > I would consider ugen to be a primary candidate to use physio like > > I belive scsi-tape drives do ? > > I don't really know the points between physio and the current way. > The story with USB bulk transfers is that legal transfers can have a > data size of even down to 0 bytes and a lot a typical clients do > small transfers - just depends on the designers needs. I might add that the INTERRUPT mode code for ugen does things in turn of 128 byte chunks, but for USB2 devices it is now permissable to use chunks of up to 1024 bytes. we should probably make that adjustable depending on whether the device is a USB 2 one or not.. Ther eis a lot to be done here to make this code really USB-2 code as opposed to USB-2 "aware" code. > In the current code it seems that short transfers are already broken > at least I don't see where short transfers can break out of the while > loop so the knowledge about the real transfers size is lost. > Under normal conditions we should break out on short transfers and > return the so far transfered size. > We should also be able to do interleaving some day. > If you think that the requirements wouldn't collide with physio then > OK. Physio simply transforms a transfer into user space in a way that the transfers don't require a buffer, but rather, use the user's buffer pages as the direct target of the transfer. You need to supply a "strategy" routine that does both read and write to the mapped buffers on behalf of physio and it tends to use system "buf" structs. > > Nevertheless I see ugen more as a quick and dirty way to test drive a > device from userland with all it's great debugging capabilities before > writing a specific kernel driver. > The requirement that ugen has to be generic is often bad for > performance sensitive applications. Ugen is used in production all over the place where people have to used devices there is no specific support for, and where there is no kernel expertise. > > -- > B.Walter BWCT http://www.bwct.de > bernd_at_bwct.de info_at_bwct.de > > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >Received on Wed Jul 07 2004 - 17:20:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:00 UTC