Re: [PATCH 08/18] PVH xen: tools changes to create PVH domain

[Mukesh Rathor <mukesh.rathor@oracle.com>]

On Mon, 17 Jun 2013 12:11:34 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:
...... 
> > > > @@ -245,6 +245,7 @@ libxl_domain_create_info =
> > > > Struct("domain_create_info",[ ("platformdata",
> > > > libxl_key_value_list), ("poolid",       uint32),
> > > >      ("run_hotplug_scripts",libxl_defbool),
> > > > +    ("pvh",          libxl_defbool),
> > > >      ], dir=DIR_IN)
> > > >  
> > > >  MemKB = UInt(64, init_val = "LIBXL_MEMKB_DEFAULT")
> > > > @@ -346,6 +347,7 @@ libxl_domain_build_info =
> > > > Struct("domain_build_info",[ ])),
> > > >                   ("invalid", Struct(None, [])),
> > > >                   ], keyvar_init_val =
> > > > "LIBXL_DOMAIN_TYPE_INVALID")),
> > > > +    ("pvh",       libxl_defbool),
> > > 
> > > I'm not quite convinced if the need for both of these bools in
> > > both create and build, it's a bit of an odd quirk in our API
> > > which I need to consider a bit deeper.
> > 
> > Ok, please let me know.
> 
> Which places need the one in c_info and which the one in b_info?
> 
> c_info is presumably for the createdomain domctl call while b_info is
> stuff spread around the build process to handle the various
> differences?
> 
> Perhaps libxl__domain_create_state is the right place for the b_info
> one, initialised internally to libxl from the c_info one? In that
> context it would be a straight bool and not a defbool since we would
> know exactly what the domain was by this point.

I think you mean libxl__domain_build_state, and not libxl__domain_create_state
right? I think I can set a field in libxl__domain_build_state in 
libxl__build_pre() and get rid of the pvh bool field from b_info, and make
it work...

thanks
mukesh