Re: latest USB code including Xenidc documentation

[Harry Butterworth <harry@hebutterworth.freeserve.co.uk>]

On Fri, 2005-12-16 at 19:38 +0200, Muli Ben-Yehuda wrote:
> On Fri, Dec 16, 2005 at 05:23:51PM +0000, Harry Butterworth wrote:
> 
> > I can do the 17 patches I posted before.  They were smaller and
> > incremental in that the code would compile cleanly when patches 1-n were
> > applied for n = 1 to 17.
> > 
> > Is that what you are looking for?
> 
> I'm afraid not. What I would like to see (and I imagine others as
> well) is a set of incremental patches, each of which is a good step
> forward on its own. Continuing to compile cleanly is a prerequisite,
> but not sufficient to be useful.

The 17 patches are each fairly self contained and provided an
incremental bit of function each time which is useful in its own right.

So, for example by the time you get to patch 3 you have a framework for
supporting different types of local memory and different types of
interdomain transfers.

> Do the USB drivers need all of the current XenIDC code to be
> functional,

Yes.  I only implemented the bits of xenidc that were required to
support the USB driver.  If you remove any of it, the USB driver will
cease to function (or in one instance slow down :-).

>  or can you post a tiny USB frontend/backend driver that
> uses the minimal ammount of XenIDC code (or none at all at first, that
> would be even better)?

The code won't work without some way to set up the comms channel and get
the command blocks and data from the FE to the BE.  At the moment this
is xenidc which is expressed in a way that is reusable between different
drivers and extensible to support different kinds of data transfers.
The whole point of the xenidc patch is to demonstrate one kind of
interdomain communication infrastructure we could have if we wanted.

I could factor out the xenidc code and put all the comms code back into
the USB driver so it was like the block and net drivers and contained
its own copy of bespoke code for messaging, data transfer and set-up but
this would entirely defeat the point of the xenidc patch.

I'm happy to do that for the USB driver if that's what people decide
they want but I'm reluctant to do it without people having first
considered the idea of having a higher level interdomain communication
API and thought about xenidc as a possible option.

> If that's possible, the next step would be to
> add useful IDC and USB driver functionality one small incremental
> patch at a time. That makes the review and submission process much
> easier, since each patch can be discussed on its own merits and
> accepted or reworked. The way the code stands right now, it's an all
> or nothing deal.

I think you are looking at it the wrong way.  The code isn't really all
that important immediately.  The most important question is do we want
the split drivers to use the low level grant-table and event-channel
APIs directly and each have their own version of code to do the required
set-up and tear-down, manipulations for buffers bigger than individual
pages and all that cruft or do we want a higher-level API that is more
convenient to use, less coupled to the intricate implementation details
and therefore better for maintenance and IMHO generally a better way.

Xenidc, the API documentation and the working USB driver serve as an
example of the kind of infrastructure we could have.  Whether we want
the end goal or not should decide how I prepare the code for
integration.  If we don't want the end goal then I can factor all the
xenidc stuff out.  If the end goal looks like a good thing, we can
discuss how to best incorporate it incrementally.

Did you read the API documentation?  Do you think it's worthwhile to try
to achieve a high level inter-domain communication API which allows
different split drivers to reuse the channel set-up, messaging,
interrupt handling, flow-control and bulk data transfer code?

Harry.

> 
> Cheers,
> Muli
-- 
Harry Butterworth <harry@hebutterworth.freeserve.co.uk>