| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH 0/3] libxl stubdom API cleanup
On Fri, 9 Jul 2010, Tim Deegan wrote:
> At 11:44 +0100 on 09 Jul (1278675850), Vincent Hanquez wrote:
> > On 09/07/10 09:17, Tim Deegan wrote:
> > >> Is it necessary to pull the mechanism out along with the policy though?
> > >>
> > > Or, if we're taking some mechanism out, couldn't we take _all_ the
> > > mechanism out?
> >
> > Which one do you have in minds ?
>
> It looks like your patch leaves some "create a stubdom" functions in the
> libxl API. I'd have thought libxl should either handle stubdoms
> entirely or not at all. (Unless stubdom creation needs some low-level
> grunge that will uglify the libxl API if it's exposed that far up - I
> can't think of any except PRIV_FOR though).
>
> > > The idea of a stub domain doesn't seem like one that
> > > libxl necessarily needs to know about.
> > >
> > yes, indeed. the stubdom create could move as a xl helper.
> > On the ocaml side reimplementing stubdom create is a trivial composition
> > of smaller libxl function (create/build/add devs) which are already bound.
>
> That sounds cleaner to me.
>
I am not so sure about this: a stubdom is not just a normal PV guest, it
also needs some special plumbings in xenstore.
By design libxl clients are not required to know about xenstore,
therefore we cannot have stubdoms entirely built by libxl clients.
I think that working around this would be worse than Vincent's current
patch series.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home