From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swwme-0007Xf-QB for qemu-devel@nongnu.org; Thu, 02 Aug 2012 10:53:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwwmY-0003by-M6 for qemu-devel@nongnu.org; Thu, 02 Aug 2012 10:53:52 -0400 Received: from cantor2.suse.de ([195.135.220.15]:42033 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwwmY-0003br-CK for qemu-devel@nongnu.org; Thu, 02 Aug 2012 10:53:46 -0400 Message-ID: <501A9474.7070609@suse.de> Date: Thu, 02 Aug 2012 16:53:40 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1343870169-16049-1-git-send-email-afaerber@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC for-1.2] arm: Move some ARM devices into libhw List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Blue Swirl , Paolo Bonzini , Anthony Liguori , qemu-devel@nongnu.org, Mark Langsdorf Am 02.08.2012 15:48, schrieb Peter Maydell: > On 2 August 2012 02:16, Andreas F=C3=A4rber wrote: >> Signed-off-by: Andreas F=C3=A4rber >> --- >> 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.MX3= 1 was >> not yet reviewed for movability. >=20 > 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) +=3D arm_l2x0.o >=20 > 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. ;) 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? >> +hw-obj-$(CONFIG_STELLARIS_ENET) +=3D stellaris_enet.o >=20 > Why just this stellaris device and not the others? I sent this out to comply with the rule of having a patch on the list by Soft Freeze date, I did not find the time to complete/update it. Either there's CPU/swap dependencies in the other files or I did not try to device'ify them yet. >> -obj-y +=3D pl041.o lm4549.o >> +obj-y +=3D lm4549.o >=20 > If we're moving the pl041 we should move its accompanying codec > (the lm4549) too, especially since the pl041 is definitely ARM > only but the lm4549 could be used on other platforms in theory. There was a merge conflict. The lm4549.o did not seem to exist when I put together the original patch. And the file names are not exactly telling, you'll have to admit. So I didn't check on that one yet, it got late enough... Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg