[Xen-tools] Some initial impressions about xenbus/xenstore

[harry <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

I'm starting to look at xenbus/xenstore in detail for the first time.
Here are my initial impressions:

I like the use of a publish/subscribe mechanism for advertising resource
availability but am concerned that the current implementation publishes
individual elements of data rather than somehow publishing complete ABI
objects.

An API can be described by a set of methods with specific parameters and
return values, a set of constraints on the legal values for parameters
and a specification of the legal sequence for calling the methods.

Depending on how the API is expressed, some aspects of the API usage can
be easily checked at compile-time, some at run-time and some not easily
checked at all.

Also, depending on how the API is expressed, it is possible to discover
some parts of the API specification by reading the code and some only
from documentation.

An API expressed in C, for example, can check that the correct number
and type of parameters are passed at compile time and the validity of
the sequence of API calls can be checked at run-time with a small extra
programming effort. The set of parameters required for each function
call can easily be determined by reading the header files but
establishing the sequence of legal function calls can only be determined
by reading documentation or the implementation in detail.

My concern therefore is that by publishing individual data items, rather
than complete ABI objects, the underlying API specification becomes
almost entirely implicit so usage of the API cannot be easily checked at
compile or run-time and the API specification cannot be easily
determined by reading the code but must instead be entirely specified by
documentation.

The use of xenstore in this way seems to me to be equivalent to
establishing an interface between objects where each party is required
to manipulate the private members of the other object.

An alternative design which I think would address this issue would
separate out the data store functionality from the publish/subscribe
mechanism such that the publish/subscribe mechanism would be used to
advertise ABI objects (as a simple example: IDC addresses for classes of
resources which would accept transactions conforming to a particular
specification expressed as a set of C structs) and the data store would
be used to store configuration data which was private to a single
component.  A design like this would have roughly the same qualities as
a C API in terms of the ease of policing the API usage, discovering the
API specification by reading the code and managing change over time.
Making the persistent data private to a single component rather than
shared would also allow that component to police all manipulations of
the data and, for example, consistently manage change across software
upgrades.

A second impression is that the level of abstraction of the inter-domain
communication mechanisms hasn't changed.  I'm still of the opinion that
it would be possible to significantly raise the level of abstraction
here to make IDC more convenient.

Finally, I think there is an important requirement which hasn't yet been
met: that a component's configuration interface ought to be discovered
dynamically by the configuration tools from the component itself such
that the low-level tools do not have to be modified at all to support a
new component added to the system.

Of these concerns, I think the first is the most significant because I
think it indicates a change of direction might be required whereas the
others might relatively easily be addressed by further development.

Also, these are only initial impressions and my understanding of the
current code is still not good, perhaps the issues above will be
addressed in the forthcoming xenbus documentation.

Harry.


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