[libvirt] cpu flags
Daniel P. Berrange
berrange at redhat.com
Wed Sep 17 13:17:36 UTC 2008
On Wed, Sep 17, 2008 at 08:44:09AM -0400, Konrad Rzeszutek wrote:
> On Wed, Sep 17, 2008 at 10:42:00AM +0100, Daniel P. Berrange wrote:
> > On Tue, Sep 16, 2008 at 04:45:09PM -0400, Ben Guthro wrote:
> > > Hi,
> > >
> > > We're finding that we are going to be needing the cpu flags (as reported
> > > in /proc/cpuinfo)
> > > ..specifically to find out if we are a vmx enabled machine.
> > >
> > > So - off I went looking into this for a patch to submit upstream.
> > > Unfortunately, I ran into some questions which need answering before I
> > > really proceed with this
> > >
> > > It seems to me that this info would best be parsed in src/nodeinfo.c
> > > This is where other cpuinfo things are parsed...and stored in the
> > > nodeinfo struct
> > > Perhaps we store this as a bitmask encoded int, as defined in
> > > /usr/include/asm/cpufeature.h and tack this onto the end of sad struct.
> > >
> > > My concern is that adding to the nodeinfo struct breaks the API - such
> > > that the structs will be different sizes between versions.
>
> Would it be possible to hack around this? For example you could use
> a unused bit of the old structure to set a flag for 'new-type-of-struct'.
> The old libvirt would ignore it, the new one would look for it.
> For example if it was an int enty and it was used as a flag entry wherein
> only 4 bits would be used, you could use the 5th bit that would
> tell it: "this is version 2 of the struct" and then the libvirt
> would cast it to the new struct which would contain the extra data-bits.
I don't want us to rely on obscure tricks like that in public facing APIs.
We have a very simple rule - everything in include/libvirt is append only.
No existing APIs or structs can be changed. New APIs & structs can be
added. Clear, easy to understand and risk free.
> This is how it is done in the RHEL kernels to work-around the kABI.
This is true, but the usage in RHEL kernels is internal API and isolated
to RHEL-5's branch of the kernel.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
More information about the libvir-list
mailing list