WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH 2/4] libxl: implementing legacy xm cpuid parser

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 2/4] libxl: implementing legacy xm cpuid parser
From: Andre Przywara <andre.przywara@xxxxxxx>
Date: Wed, 22 Sep 2010 14:42:51 +0200
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Wed, 22 Sep 2010 05:47:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19608.53676.446126.946833@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4C98B294.4000909@xxxxxxx> <19608.53676.446126.946833@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.23 (X11/20090820)
Ian Jackson wrote:
Andre Przywara writes ("[PATCH 2/4] libxl: implementing legacy xm cpuid 
parser"):
To support legacy xm-based config files, add a parser for the old
style cpuid= syntax. This uses a Python list, so it can be
distinguished from the new syntax easily.

Thanks.  This is going in the right direction.

I'm not sure I like the word "legacy".  Eventually we'll have several
compatibility things all of which will be called "legacy" and no-one
will know what's what.  I would have called it
"libxl_cpuid_parse_config_xend_compat" or something.
I fixed this and renamed it to _xend (omitting compat).


Also, why are you exposing to xl directly the fact that there are
these two kinds of cpuid parameter ?
Because the differentiation between xend and new xl way (Python list vs. string) is in the parsing routines in xl_cfg_*. To see the direction I am going to I attached the first draft version of my upcoming multicore patch. This uses the interface provided by libxl_cpuid_parse_config(). IMHO this is a very readable and maintainable approach, and it can be overridden by cpuid lines (or forced again later by being called after the cpuid= parsing).

Is it possible to hide this in
libxlu somehow ?  That way future callers who need to parse the same
strings (eg, when libvirt calls libxl) can just call the code rather
than having to move it and/or replicate it.
I am not 100% sure if it is what you want, but I could move the strtok() part which splits up the cpuid= string into the parse_config function. But this would make the multicore patch uglier to implement, so I refrained from it. Beside that it allows for easy substring-specific error reporting to be handled completely by the caller (xl_cmdimpl.c in this case).

What would be the interface libvirt wants to use? Would it use parse_config_data()? If not, libvirt would have to re-implement parts of this function anyway. If yes, it would work automatically.

Regards,
Andre.


So I think most of the code you add to xl_cmdimpl.c should be in
libxlu (or perhaps libxl).

Ian.



--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12


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

<Prev in Thread] Current Thread [Next in Thread>