Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 9 Feb 2012, Ian Campbell wrote:
> On Thu, 2012-02-09 at 16:00 +0000, Stefano Stabellini wrote:
> > On Thu, 9 Feb 2012, Ian Campbell wrote:
> > > On Thu, 2012-02-09 at 15:32 +0000, Stefano Stabellini wrote:
> > > > On Thu, 9 Feb 2012, Ian Jackson wrote:
> > > > > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 20 of 29 RFC] 
> > > > > libxl: introduce libxl hotplug public API functions"):
> > > > > > - we can reuse the "state" based mechanism to establish a 
> > > > > > connection:
> > > > > > again not a great protocol, but very well known and understood.
> > > > > 
> > > > > I don't think we have, in general, a good understanding of these
> > > > > "state" based protocols ...
> > > > 
> > > > What?! We have netback, netfront, blkback, blkfront, pciback, pcifront,
> > > > kbdfront, fbfront, xenconsole, and these are only the ones in Linux!!
> > > 
> > > And no one I know is able to describe, accurately, exactly what the
> > > state diagram for even one of those actually looks like or indeed should
> > > look like. It became quite evident in these threads about hotplug script
> > > handling etc that no one really knows for sure what (is supposed to)
> > > happens when.
> > 
> > I thought that most of the thread was about the interface with the block
> > scripts, that is an entirely different matter and completely obscure.
> > If I am mistaken, please point me at the right email.
> 
> We are talking about reusing the existing xenbus state machine schema
> for a new purpose. Ian J pointed out that these are not generally well
> understood, you replied that it was and cited some examples. I pointed
> out why these were not examples of why this stuff was well understood at
> all, in fact quite the opposite.

Sorry but I don't understand how these examples are supposed to be
"quite the opposite".
I quite like the idea of being able to read a single source file of less
than 400 LOC to understand how a protocol works
(drivers/input/misc/xen-kbdfront.c).
In fact I don't think that understanding the protocol has been an issue
for the GSoC student that had to write a new one.
I think we are under influence of a "reiventing the wheel" virus.


> > > Justin just posted a good description for blkif.h which included a state
> > > machine description. We need the same for pciif.h, netif.h etc etc.
> >  
> > The state machine is the same for block and network.
> 
> No, it's not. This is exactly what IanJ and I are talking about.

Could you please elaborate?

I am sure you know that the xenstore state machine is handled the same
way for all the backends in QEMU (see hw/xen_backend.c).
And the same thing is true for the frontends and the backends in Linux.

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