Re: xend leaks/bugs/etc

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

On Mon, 2005-04-18 at 10:15 -0500, Anthony Liguori wrote:
> Harry Butterworth wrote:
> >The problem here is that the inter-domain communication primitives are
> >very low level and separated into a notification channel, a message
> >channel and a facility for bulk-data transfer which are all provided
> >independently.  The client of these interfaces must use them together to
> >make a communications channel but, because they are provided separately
> >with no constraints on correct relative sequencing of the three
> >interfaces the complexity from the client's perspective is cubed.
> >  
> >
>  From the perspective of the driver, the IDC primatives shouldn't 
> matter.  All a discovery-driver should have to do is maintain a 
> discovery state and examine every message of a certain type and 
> determine how to change it's state and generate additional messages when 
> necessary.
> 
> The discovery-drivers should be obvilious to how the messages are 
> actually delivered.

Exactly.  Contrast that with the current implementation where each new
driver reimplements and is explicitly coupled to a specific delivery
mechanism.

> >2) Define a high level inter-domain communication API.  This should be
> >consistent with the cluster model, should define the domain lifecycle
> >and contain sufficient guarantees for general purpose use. In particular
> >the API should deal with domain connection/disconnection notification
> >and elimination of stale communications. The inter-domain communication
> >API must be compatible with a MAC security implementation.
> >  
> >
> I'm not sure this is necessary.  The registry should all but implement 
> the tools interaction with IDC.  The real use will be for console data 
> and there's been talk for a while about moving the console's out of the 
> control channel.  This would simplify things even further.

As well as the inter-domain communication for tools interaction, all the
FE and BE driver comms require inter-domain communication to implement
their device-specific protocols.  There ought to be a single general
purpose underlying API which is minimal and sufficient from the client's
perspective. The existing API (notification/shared memory/grant tables)
is sufficient but not minimal from the client's perspective because of
the complexity of the three independent mechanisms and the interaction
with the sketchy domain lifecycle model.

> 
> >3) Define a dynamic resource discovery mechanism for use, for example,
> >by FE and BE driver domains.  This mechanism probably ought to be a
> >service accessible over the inter-domain communication API.
> >  
> >
> I believe this is the purpose of xenbus.

What is this xenbus of which you speak?  Any public discussion/docs
around?  I heard one mention of xenbus at the summit.  I have to admit
I've not been following checkins to unstable recently but I have been
keeping an eye on the devel-list and haven't noticed anything about it.

> 
> >4) Define a configuration mechanism framework.  The last tools document
> >I read coupled the configuration aspects to the resource discovery
> >aspects.  I think they are distinct: the resource discovery mechanism
> >deals with dynamic changes which are not necessarily under user control
> >(loss of availability for example) whereas the configuration mechanism
> >is used by the user or higher level management tools to specify the
> >desired system configuration.
> >  
> >
> I'm wary of standardizing configuration although I'm curious to hear 
> thoughts on it.

You can't standardize configuration itself because all the different
aspects are necessarily different in detail but you can provide a
standard  extensible framework consistent with the cluster architecture
that solves the aspects common to all configuration activity.  For
example, making configuration activity fault-tolerant can have a common
solution if that is a requirement.

Harry