Re: [Xen-devel] [PATCH 2 of 5] blkif.h: Provide more complete documentation of the blkif interface

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2012-02-08 at 23:24 +0000, Justin T. Gibbs wrote:
> On Feb 7, 2012, at 10:51 AM, Ian Jackson wrote:
> 
> > Justin T. Gibbs writes ("[Xen-devel] [PATCH 2 of 5] blkif.h: Provide more 
> > complete documentation of the blkif interface"):
> >>  o Document the XenBus nodes used in this protocol
> > 
> > Awesome.  But I don't think all of these are really supposed to be
> > part of the guest interface, so you should probably mention which ones
> > are.
> > 
> > For example,
> > 
> >> + * params
> >> + *      Values:         string
> > 
> > this is not intended for use by guests and they should not look at it.
> 
> Guests can export back-end devices.  Here at Spectra we do this all the
> time. :-)

I think Ian meant "guest" in the sense of "frontend", while a backend,
even one running in a driver domain, would  be considered some sort of
service domain rather than a "guest". IOW a "guest" is the purpose for
which you are virtualising, while other domains and just part of the
platform

I admit the terminology is not terribly well defined though.

> It would be hard to implement a blkback driver without this information.
> The comment at the top of your email implies you're okay with it being
> in this file, but that I should mark "local-end use only" nodes?

I think that makes sense, "back-end only" or perhaps some allusion to it
being part of the tools->blkback configuration might express it better?

> > 
> >> + * virtual-device
> >> + *      Values:         <uint16_t> (XEN_*_MAJOR << 8 | Minor)
> > 
> > This should be a reference to docs/misc/vbd-interface.txt.  But isn't
> > this also encoded in the device path in xenstore ?
> 
> It would appear so.  Should this path naming convention be mandated by
> this file?  Since "virtual-device" exists, it seems that front-ends should
> read it, not parse the path, to determine this information.

This seems sensible and matches the actual behaviour of, at least, the
Linux frontend.

Ian.


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