From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mt8ab-00064q-FI for qemu-devel@nongnu.org; Wed, 30 Sep 2009 19:28:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mt8aX-00063W-QM for qemu-devel@nongnu.org; Wed, 30 Sep 2009 19:28:05 -0400 Received: from [199.232.76.173] (port=55556 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mt8aX-00063Q-Nz for qemu-devel@nongnu.org; Wed, 30 Sep 2009 19:28:01 -0400 Received: from mail-ew0-f221.google.com ([209.85.219.221]:33705) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mt8aX-0000l6-D4 for qemu-devel@nongnu.org; Wed, 30 Sep 2009 19:28:01 -0400 Received: by ewy21 with SMTP id 21so6706295ewy.8 for ; Wed, 30 Sep 2009 16:28:00 -0700 (PDT) Message-ID: <4AC3E97C.7070005@codemonkey.ws> Date: Wed, 30 Sep 2009 18:27:56 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] RFC configurable block formats References: <873a64dyit.fsf@pike.pond.sub.org> In-Reply-To: <873a64dyit.fsf@pike.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org Markus Armbruster wrote: > 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. > I'd rather see something like a driver white list/black list for qemu proper. The list would be used to exclude block formats and could be extended to support read-only formats vs. read-write formats. For instance, --enable-block-formats='qcow2 raw'. It avoids polluting the block interface with knowledge of the distinction between a "utility" program and qemu proper. Regards, Anthony Liguori