All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] RFC configurable block formats
Date: Wed, 30 Sep 2009 18:27:56 -0500	[thread overview]
Message-ID: <4AC3E97C.7070005@codemonkey.ws> (raw)
In-Reply-To: <873a64dyit.fsf@pike.pond.sub.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

  reply	other threads:[~2009-09-30 23:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-30 19:26 [Qemu-devel] RFC configurable block formats Markus Armbruster
2009-09-30 23:27 ` Anthony Liguori [this message]
2009-10-01 20:29   ` Markus Armbruster
2009-10-01 21:25     ` Anthony Liguori
2009-10-02 12:52     ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AC3E97C.7070005@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=armbru@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.