On 2 August 2012 15:53, Andreas Färber <afaer...@suse.de> wrote: > Am 02.08.2012 15:48, schrieb Peter Maydell: >> On 2 August 2012 02:16, Andreas Färber <afaer...@suse.de> wrote: >>> Signed-off-by: Andreas Färber <afaer...@suse.de> >>> --- >>> Hello Peter, here's my current draft for subjecting more arm devices to the >>> stricter device checks in libhwX. Please review desired granularity (here: >>> fine-grained) and naming (e.g., PL310 vs. l2x0). >>> Since this is preparing for a future armeb-softmmu, Anthony's >>> CONFIG_ARCH_ARM >>> is not going to help here (we would want to turn off many devices for >>> armeb). >>> The SoCs with references to CPUs in their header are untouched, i.MX31 was >>> not yet reviewed for movability. >> >> So what's our long term vision here? Every device has a CONFIG_FOO that >> gets turned on in some default-configs/ file? > > The general idea is to set good examples for authors of new devices and > to prepare for armeb: To me, that calls for disabling all ARM devices > apart from those whitelisted / strictly needed for BE. > > And for me personally to reduce build times when changing CPU things: > Currently way too many files are needlessly rebuilt because they happen > to trigger a cpu.h dependency (NEED_CPU_H) due to sitting in the "wrong" > Makefile. > > Another, independent long-term vision would be to place arm files into > hw/arm/, to put some more structure into the looong list of hw/ files. > But moving files around would be a task for you to do on your > arm-devs.next queue to not interfere with any ongoing device work. The > difference between devices and machine stuff would then be obj-y vs. > hw-obj-y as Anthony explained to me in the kvm/ context. > >> What are the 'stricter checks' you mention? > > Poisoning certain identifiers (Blue's initiative, I believe), no > explicit guest-dependent swaps and other limitations incurred by > cpu.h-less headers. > >>> +hw-obj-$(CONFIG_PL310) += arm_l2x0.o >> >> Maybe we should have named the source file pl310.c... > > That was one of my RFC points - not sure how to interpret the header: Is > this multiple devices in one? Or different names for the same thing? > I just found it looked nicer this way. ;)
Basically the (hardware) device was renamed to match the other PL*, but from an engineering pov the PL310 is just the newer version of the L220 (which in turn is the newer version of the L210); they're all very similar from a programmer's view perspective. I think 'l2x0' comes from what the kernel calls it. > Independent of that, do we need to separate things on that granularity > at all? Or just do CONFIG_PL or something? > In practice, it seemed that usage of these devices is rather fragmented > (not all boards use all PLxxx devices) so that per-device config names > as in master allow for fine-grained control of which devices get built > if only armeb-softmmu were to be built; > on the other hand if that seems too complicated the alternative question > to ask would be, are all PLxxx devices theoretically capable of being > used for armeb as well? They should in theory be OK on a big-endian system, but then in theory just about any device should be OK on a big endian system: device/system endianness and CPU endianness are orthogonal. -- PMM
