[Libvirt-cim] [PATCH] (#2) ProcessorRASD, the class that won't go away

[Jay Gagnon]

Jay Gagnon wrote:
> # HG changeset patch
> # User Jay Gagnon <grendel at linux.vnet.ibm.com>
> # Date 1211234740 14400
> # Node ID d9042b4ea61771df5110e97872c9e504f71859e7
> # Parent  c949b1845113e11e01329abb5aa81ca6ade8e3ec
> (#2) ProcessorRASD, the class that won't go away
>
> Around and round we go on the merry-go-round of indecision, hopefully for our last ride.  The definitely probably absolutely tentative final plan is that the default representation of processors as virt_device structs will be one per domain, with a quantity.  Virt_Devices will just need to be told how to handle that, and all the RASD stuff will be much happier for it.  And then we will never speak of this again.
>
> So today being my last official day on the team, I kind of have to get this out in a not perfect state.  From what I can see it does what it is supposed to do, but it is entirely possible (likely?) that there are a few things in here that aren't really great things to do.  I wish I could polish it more but I think I've at least got it to the point where any work left to be done is generic "not a great idea in C" problems, as opposed to the much more annoying "what exactly are we supposed to do in this case" problems.
>
> Changes from 1 to 2:
> Close brace on if block.  That one is really embarrassing; I have no idea what happened there.  I mean that crap won't even compile.
> Removed unnecessary proc_found boolean.  That was me being lazy after changing my mind on something.
> Cleaned up a couple leftover CU_DEBUG calls.
> Addition of vcpu_inst function, which is similar to vcpu_instances but always only works on one instance and takes a dev_id.  This is to prevent all instances from being given a dev_id of zero.  It is unfortunately similar to vcpu_instances in other regards, but I'm not sure if it's worth the overhead of trying to combine the similar parts.
> Fixed quantity v number problem in xml_parse_test that I appear to have been failing to address for about six years.
>
> Signed-off-by: Jay Gagnon <grendel at linux.vnet.ibm.com>
> Signed-off-by: Kaitlin Rupert <karupert at us.ibm.com>
> Signed-off-by: Dan Smith <danms at us.ibm.com>
>
>
>   
Some time last night I realized that the vcpu_isnt and vcpu_instances 
functions *can* be combined in a useful way.  Instances can just alter 
it's loop to call inst each iteration.  Silly of me to not see that the 
first time.  I can either resend or send as a second patch; it's not 
gonna to change any actual behavior so it's not a critical 
must-apply-immediately scenario, but it will make for slightly better code.

-- 

-Jay