From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M3Y0x-0001EQ-KR for qemu-devel@nongnu.org; Mon, 11 May 2009 12:06:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M3Y0s-0001Bm-2o for qemu-devel@nongnu.org; Mon, 11 May 2009 12:06:02 -0400 Received: from [199.232.76.173] (port=55315 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M3Y0r-0001BW-Kc for qemu-devel@nongnu.org; Mon, 11 May 2009 12:05:57 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:55205) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M3Y0p-0004Ju-Vh for qemu-devel@nongnu.org; Mon, 11 May 2009 12:05:56 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e37.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4BG57hM009554 for ; Mon, 11 May 2009 10:05:07 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4BG5eeB198836 for ; Mon, 11 May 2009 10:05:40 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4BG5d2h032476 for ; Mon, 11 May 2009 10:05:39 -0600 Message-ID: <4A084CD2.7070108@us.ibm.com> Date: Mon, 11 May 2009 11:05:38 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1242052009-27339-1-git-send-email-aliguori@us.ibm.com> <200905111548.48216.paul@codesourcery.com> In-Reply-To: <200905111548.48216.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/4][RFC] Add module infrastructure to QEMU List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org Paul Brook wrote: > On Monday 11 May 2009, Anthony Liguori wrote: > >> This is the current state of a patch set to introduce a module >> infrastructure to QEMU. >> > > I don't think numeric priorities are a good idea. If we have dependencies then > we should be dealing with them properly, not hacking round the problem. > The numeric priorities are an implementation detail. No one should ever consume module_init() directly and I should add appropriately scary comments to that affect. The numeric priorities are currently used to implement a simple dependency tree with each level of the tree being an integer priority. We do have dependencies. I'd like virtio to be a module, and I'd like virtio-net, virtio-blk, etc. to be modules. This gets exposed as virtio.c being a bus_init() and virtio-*.c being virtio_init(). We use the integer priorities in module.h to express this. We could get fancier and have explicit dependencies by name or something like that. I'm not sure I think it's worth getting this complex though. > Also, there's no reason to have destructors. The init function can register > these at runtime. > I don't feel strongly here. The one case I think it could prove useful is that a number of things require atexit functions today. I think it would be good to use destructors to make these more standardized. Also, deregistering components has the advantage of making valgrind much happier. We don't deregister the block drivers in this patch series, but I can certainly add it. >> 2) Switch to using dynamic shared libraries. This has the benefit of >> reducing the QEMU install size. This is attractive except for the fact >> that creating dynamic shared libraries across multiple host architectures >> is a pain. >> > > In practice I'd expect the shared library overhead (both disk and RAM) to be > significantly larger than the saving form omitting a few devices. As you said > before, if we're not using something, why build it in the first place? > > There's also the issue that shared libraries imply it's OK for third parties > to ship binary plugins. > I'm strictly talking about libqemu_common.a and libqemu_user.a. However, I really don't want to do shared libraries in the absence of automake because shared libraries require a lot of per-platform foo to create. I'm happy ruling this out. Regards, Anthony Liguori > Paul > -- Regards, Anthony Liguori