On Tue, Dec 01, 2015 at 02:53:24PM +1100, Alexey Kardashevskiy wrote:
On 12/01/2015 02:12 PM, David Gibson wrote:
On Tue, Dec 01, 2015 at 01:43:10PM +1100, Alexey Kardashevskiy wrote:
On 11/30/2015 07:51 PM, David Gibson wrote:
Signed-off-by: David Gibson <address@hidden>
---
hw/ppc/spapr.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 3d31fe7..f680497 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2334,9 +2334,9 @@ static const TypeInfo spapr_machine_info = {
machine_init(spapr_machine_register_##suffix)
/*
- * pseries-2.5
+ * pseries-2.6
*/
-static void spapr_machine_2_5_class_compat(MachineClass *mc)
+static void spapr_machine_2_6_class_compat(MachineClass *mc)
{
sPAPRMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
@@ -2344,7 +2344,17 @@ static void spapr_machine_2_5_class_compat(MachineClass
*mc)
mc->desc = "pSeries Logical Partition (PAPR compliant)";
}
-DEFINE_SPAPR_MACHINE(2_5, "2.5", NULL, true);
+DEFINE_SPAPR_MACHINE(2_6, "2.6", NULL, true);
+
+/*
+ * pseries-2.5
+ */
+static void spapr_machine_2_5_class_compat(MachineClass *mc)
+{
+ spapr_machine_2_6_class_compat(mc);
+}
+
+DEFINE_SPAPR_MACHINE(2_5, "2.5", NULL, false);
/*
* pseries-2.4
After this patch, "smc->dr_lmb_enabled = true" moved to
spapr_machine_2_6_class_compat() from spapr_machine_2_5_class_compat(), was
that on purpose?
Yes. 2.6 wants dr lmb enabled as well, which means 2.5 doesn't need
it because it calls the 2.6 function. The significant part of the
history is where the 2.4 function turns if *off* again.
And then "smc->dr_lmb_enabled = true" will have to jump to new
spapr_machine_2_7_class_compat() (or whatever version it will be by then)?
Uff. ok.
I'd just understand it better if there was
spapr_machine_default_class_init() which would set everything "on" and the
latest default spapr_machine_X_Y_class_compat() would call it directly; the
lower version class_init()s would call upper level (as the patchset does)
and disable individual features.
Yeah, I had something like that in an earlier draft and decided it
wasn't worth it. I think you've concinved me to change my mind again,
though.
And spapr_machine_class_init() would only initialize class callbacks but not
touch the features.
Hmm.. actually that's maybe a better approach - make
spapr_machine_class_init() take the place of
spapr_machine_default_class_init() but update it so it's actually
correct for the latest defaults, which it isn't right now.