Re: USB virt status

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

On Sat, 2005-11-05 at 00:50 +0000, Mark Williamson wrote:
> > Most of the difficulty is in working with xenstore, which is deeply
> > inconvenient as a tool for sequencing dependent operations.  That's what
> > resulted in the state machine I posted to the list as a ps file.  You
> > could probably hack this state machine into the existing drivers with
> > only a small amount of additional code but it will just make the drivers
> > even more ugly and incomprehensible than they are already.
> 
> Yes, right now I'm working with Xenstore too.  The updates I mentioned are 
> supposed to tackle this problem by providing a better API, automating the 
> channel setup state machine for the majority of users (i.e. all devices).  I 
> believe a some of this code is fully completed and awaiting push to the main 
> tree once it's been reviewed by a few people.

Really? I haven't seen any discussion about this on the list.  Or any
patches for review for that matter.  Another private Cambridge clique?

> 
> > The main reason for me to write the API was to have something concrete
> > to code the USB driver against whilst the Xen infrastructure was in
> > flux---previously the two changes to xend and the change to grant-tables
> > had caused me a huge amount of rework.  The API allowed me to complete
> > the driver whilst the infrastructure was stabilising.
> 
> Surely you still had to update the code just as often?  I guess having it 
> separated would at least ease the update burden.  I've rewritten my code 
> several times for the control plane also; it's tough working out-of-tree for 
> long periods based on the unstable tree.

No, after I stopped trying to sync up with the xenbus-of-the-week API I
just defined the API I wanted, coded my driver to it and it's only been
in the last few weeks that I've been implementing the API.  Thankfully
the xenbus and grant-table interfaces haven't changed enough to
completely break me since then. And, yes, you'll find it is much easier
to update the code when it isn't all munged together in one big lump.

> 
> > Rather than remove the xenidc stuff, I think it would be much more
> > useful to pick up the xenidc code for general use, base all new drivers
> > on it and eventually port the block and net drivers to it.  This would
> > allow you to change the infrastructure underneath all new drivers
> > relatively easily and I would expect it to save you a significant amount
> > of effort when implementing new drivers, when optimizing the code and,
> > in the future, if you extend the system over the network or do any fancy
> > page sharing.
> 
> I really would have liked to see a more abstract interface to communications, 
> such as the one you propose.  However, it is not going to happen for the 3.0 
> release and that's when the team promised the interfaces will be frozen.  If 
> it can't be compatible with the existing interfaces, that's going to make it 
> much less likely that anyone will update the existing drivers and then 
> maintain two separate interdomain interfaces for each.
> 
> I think the project is likely to follow the path of least resistance and go 
> with a "xenstore connection setup library" that replaces most of the 
> duplicate code but retain the old datapath API.  I get the impression this 
> decision has been taken already.

This doesn't seem to have been discussed on the list either.

> > When I've got the code up and working and have split the patch up into a
> > series of manageable chunks you should judge it on technical merit.  I
> > would expect that peer review will find ways to improve the
> > implementation and perhaps make it fit better with Xen but I'm confident
> > that the basic design is reasonable.
> 
> I agree, but regardless of the goals of the basic design it's going to be 
> harder to get a merge for a driver that implements its own complex 
> abstraction layer than for one which uses the Xen APIs directly.  I'd like to 
> have a nicer driver API but if that isn't accepted then we're probably better 
> with the drivers as small as possible.
> 
> It's an unfortunate situation; what you propose is a nice way of doing things 
> but doesn't appear to be gaining much traction yet.  If the USB driver is 
> going to be predicated on it I'd suggest having a clear plan about how you're 
> going to get the generic IDC code into the main tree - I'm not sure whether 
> rolling it in with the USB driver itself will be accepted.

Current plan: write good quality generic code which is reusable and
useful to other drivers.  Document and break patch down into manageable
chunks.  Get in to the tree on technical merit.

In any case, I can always change the implementation of the xenidc code
to base it on whatever API you provide.  This is what it was designed
for. So at least I won't have to rewrite the driver again.

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