From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ir8f8-0004w7-ND for qemu-devel@nongnu.org; Sun, 11 Nov 2007 03:59:26 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ir8f6-0004vi-9B for qemu-devel@nongnu.org; Sun, 11 Nov 2007 03:59:25 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ir8f5-0004vd-QO for qemu-devel@nongnu.org; Sun, 11 Nov 2007 03:59:23 -0500 Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ir8f5-0002cP-16 for qemu-devel@nongnu.org; Sun, 11 Nov 2007 03:59:23 -0500 Received: from nf-out-0910.google.com ([64.233.182.190]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ir8f4-00076l-8K for qemu-devel@nongnu.org; Sun, 11 Nov 2007 03:59:22 -0500 Received: by nf-out-0910.google.com with SMTP id 30so814615nfu for ; Sun, 11 Nov 2007 00:59:20 -0800 (PST) Message-ID: Date: Sun, 11 Nov 2007 10:59:20 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] Splitting vl.h In-Reply-To: <200711110422.24440.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200711110422.24440.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 11/11/07, Paul Brook wrote: > The attached patch starts splitting vl.h up a bit. > I've pulled out the i2c, disk and irq code. > > Because I picked some of the easier ones, they can also be built once, rather > than for every target. > > Obviously there's a lot left to do, but my grand plan is to get rid of vl.h > altogether. A few files will probably end up effectively including > everything, but hopefully most files should disentangle reasonably well. The > more gets split out, the better things should get. e.g. scsi-disk.c doesn't > need vl.h because I already split out the block API. > > I want to check this seems a reasonable approach before I go too much further. > Comments? I understand Fabrice's concern about small files, but I think this is the right direction. In ide.c and esp.c there are TARGET_ and target_ dependencies, how do you plan to handle those?