On 2012-06-18 14:47, Anthony Liguori wrote: > On 06/18/2012 04:13 AM, Jan Kiszka wrote: >> On 2012-06-18 02:32, Andreas Färber wrote: >>> Am 18.06.2012 02:01, schrieb Anthony Liguori: >>> This will work technically but I still feel this is wrong semantically. >>> The pre-Paolo and current way is picking specific files from the hw/kvm/ >>> directory. Your change above implies that in hw/kvm/ only x86 files can >>> live, which I dislike. As suggested before, I would prefer if x86-only >>> files were moved to an x86-specific location - the place for that >>> existing since Paolo's refactoring would be hw/i386/. CC'ing Jan. That >>> would match Paolo's reply in the unicore32 thread on future file >>> placement. Alternatives would be hw/i386/kvm/ or hw/kvm/i386/; we're >>> talking about a handful of files only though, so I don't think they >>> require a new subdirectory. >> >> Some per-arch separation is required, at least in the build process. >> We'll see power and arm stubs for in-kernel devices soon. > > i8259.o i8254.o ioapic.o don't need to be arch specific
In theory. In practice they carry quite a bit of the PC architecture (i8254: HPET and PC speaker port, i8259: ELCR). Maybe not the IOAPIC. It was once reused on IA64, but that arch is dead. > > apic.o ought to be renamed to lapic.o and moved to target-i386/kvm/ "apic" is fine as name as the code covers both cases. Should be move hw/apic* as well? > > I think clock.o also more than likely belongs in target-i386/kvm/. It would > have to be implemented as part of the CPU core if it ever existed IRL. > > In general, if is logically part of a CPU core, it ought to be in > target-$(ARCH). Otherwise, it shouldn't be built as a target specific object. There are some practical things like lacking types or defines in the KVM API that most probably prevent building certain KVM devices for all targets unconditionally. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
