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/
Home Products Support Community News


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

To: Andre Przywara <andre.przywara@xxxxxxx>
Subject: [Xen-devel] Re: [PATCH 2/4] libxl: implementing legacy xm cpuid parser
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Date: Tue, 21 Sep 2010 16:39:24 +0100
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Tue, 21 Sep 2010 08:40:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C98B294.4000909@xxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Andre Przywara writes ("[PATCH 2/4] libxl: implementing legacy xm cpuid 
> 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.

Also, why are you exposing to xl directly the fact that there are
these two kinds of cpuid parameter ?  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.

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


Xen-devel mailing list

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