On 12/07/2011 01:35 AM, Matt Evans wrote: > Hi Scott, > > On 07/12/11 05:03, Scott Wood wrote: >> On 12/05/2011 10:05 PM, Matt Evans wrote: >>> This patch adds a new arch directory, powerpc, basic file structure, register >>> setup and where necessary stubs out arch-specific functions (e.g. interrupts, >>> runloop exits) that later patches will provide. The target is an >>> SPAPR-compliant PPC64 machine (i.e. pSeries); there is no support for PPC32 or >>> 'bare metal' PPC64 guests as yet. Subsequent patches implement the hcalls and >>> RTAS required to boot SPAPR pSeries kernels. >> >> You just sent out 28 patches removing "everything is x86" >> dependencies -- may I suggest that the PPC code be structured so that >> there isn't an "everything on PPC (or even PPC64) is SPAPR" assumption, >> even if SPAPR is initially the only sub-arch present? > > I had anticipated this comment (though not the "28 patches" remark, easy now). I was just using that to illustrate how it's easier to handle earlier than later -- no offense intended. :-) > It is a fair comment, but you hit the nail on the head with your other mail > (regarding configuring in i8042, presumably to emulate crappy dev boards) > asking whether kvmtool has a config system. It does not. > > Since we currently lack any kind of build-time configuration (or any fancy > run-time -M <machine> a la QEMU) it's a bit hard to cater for multiple > platforms. I'm aware that the PPC patches are painfully PPC64-with-SPAPR and I > don't present them as perfect, but I really think we need to attack the > configuration stuff before bifurcating. Is this something you'd like to see to? Just putting all SPAPR stuff in SPAPR-named files (or at least SPAPR-named functions), and likewise for book3s stuff, etc. would be an improvement. I see that you did this for some things, but not all. Try to make it obvious where the target-specific branching would take place, even if the actual branching mechanism is currently just a FIXME comment. -Scott -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
