Re: [Xen-devel] USB virt 2.6 split driver patch series

[harry <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

On Tue, 2005-11-22 at 02:02 +0900, NAHieu wrote:
> On 11/22/05, harry <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > On Tue, 2005-11-22 at 00:27 +0900, NAHieu wrote:
> >
> > > If you think 8 spaces is too long, you could reconfigure your editor.
> > > For example I use vim as editor, and configure it to display 4 spaces
> > > for 1 tab (set shiftwidth=4), and the code looks much better.
> >
> > Thanks, I hadn't thought of that.
> >
> > > Beside spliting the code and send them to the list, could you send a
> > > whole in 1 file only? I want to patch it to my tree and give it a try.
> > > Downloading 17 files separately and patch them is tired ;-)
> >
> > Here you go...
> >
> 
> Harry, what is the intentional usage of xenidc in drivers/xen/,
> besides to support usb driver?

It's intended to be generally useful.  So if you wanted to write another
driver you could use the xenidc_endpoint and rbr provider and mapper
pools in the new driver.

The local and remote buffer reference types can be extended as well: the
current code is sufficient for drivers like the USB driver which want to
map kernel virtual address space into the back end.  This would probably
be OK for use by an audio split driver as well and maybe the block
driver.  The network driver or similar drivers which need to swap pages
around would require different local buffer reference and remote buffer
reference types to describe the kind of memory management manipulations
they needed.  It's possible to define and install new types of buffer
references and the generic code will still work with them to do the
resource management etc.

The endpoint code includes the shared page allocation/setup, ring
buffers, interrupt handlers, use of memory barriers, use of grant
tables, some use of xenbus and the set-up/tear-down state machine which
is quite subtle.  Currently this code is replicated in all the other
drivers.  I didn't want another copy in the USB driver so I factored it
all out for common use.

The rbr provider and mapper pool is the bulk data transfer code which
again is replicated in all the other drivers.  Currently the block and
net drivers have different implementations of this but in general there
will be fewer kinds of bulk data transfer required than there will be
drivers so it will be undesirable to have an implementation of bulk data
transfer in every driver.  Again this code is factored out of the USB
driver into a common service.  The common service can be extended for
the different classes of bulk data transfer that will be required for
different classes of device.

> 
> Thanks.
> Hieu
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel