From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mt4pH-000446-8I for qemu-devel@nongnu.org; Wed, 30 Sep 2009 15:26:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mt4pC-0003xJ-M2 for qemu-devel@nongnu.org; Wed, 30 Sep 2009 15:26:58 -0400 Received: from [199.232.76.173] (port=49174 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mt4pC-0003xA-94 for qemu-devel@nongnu.org; Wed, 30 Sep 2009 15:26:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64167) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mt4pB-0000YT-Pq for qemu-devel@nongnu.org; Wed, 30 Sep 2009 15:26:54 -0400 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8UJQqOS013659 for ; Wed, 30 Sep 2009 15:26:52 -0400 Received: from pike.pond.sub.org (vpn-10-126.str.redhat.com [10.32.10.126]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n8UJQpY7018072 for ; Wed, 30 Sep 2009 15:26:51 -0400 From: Markus Armbruster Date: Wed, 30 Sep 2009 21:26:50 +0200 Message-ID: <873a64dyit.fsf@pike.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] RFC configurable block formats List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org We have code for a quite a few block formats. A quick grep shows bochs, cloop, cow, dmg, ftp, ftps, host_cdrom, host_device, host_floppy, http, https, nbd, parallels, qcow, qcow2, raw, tftp, vdi, vmdk, vpc, vvfat. Only formats ftp, ftps, http, https, tftp are optional (see configure --enable-curl). While I trust that all of these formats are useful at least for some people in some circumstances, some of them are of a kind that friends don't let friends use in production. In short, I'd like to be able to configure block formats. Simple enough, eh? Except there's a catch: I'd like to be able to include more formats in tools like qemu-img than in qemu proper. That lets me restrict qemu proper, where a faulty block driver has the greatest potential for mischief, to the formats I trust and need, and still keep useful capability for other formats in qemu-img. Thus, I'd like to be able to configure a block driver off for everything, or on for utility programs and off for qemu proper, or on for everything. A naive implementation of this idea simply links only those block drivers into a program that have been configured for it. Unfortunately, this leads to an unwanted difference in behavior between the different programs when the format is probed. Probing gives every block driver a chance to "score" the image, and picks the one with the highest score (I'm simplifying, but it'll do to illustrate the problem). If two programs have different sets of drivers, probing may yield different results. I don't like that. Say I configure crusty old qcow (note lack of 2) for utility programs only. Then I don't want qemu to silently treat qcow images as raw, I want it to tell me it can't do qcow. To be precise: If a format is configured off, no program shall recognize it. Else all programs shall recognize it, but if it is configured on for utility programs, off for qemu proper, then recognizing it in qemu proper shall be an error. If you agree this is useful, I'd be willing to code it.