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. This is how it is done in the RHEL kernels to work-around the kABI. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list