[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 4/4][RFC] Add logic to QEMU to read command line

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 4/4][RFC] Add logic to QEMU to read command line options from qcow2 images
Date: Thu, 09 Aug 2007 15:49:10 -0500
User-agent: Thunderbird (X11/20070728)

Brian Wheeler wrote:
On Thu, 2007-08-09 at 15:32 -0500, Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
If you're looking for a low-end solution, another possibility would be having a "new" file format which consisted of:

#!/path/to/qemu [<args> ...] <nl>
<standard disk image>

And then make the appropriate changes to QEMU such that it can skip the first line in a disk image file. This has a few nice side effects. The disk image is directly executable and it makes it very clear to the user that they have to trust the disk image. The other nice thing is that it would work with file formats other than qcow2.
Well, it would be nice to align the disk image to a sector boundary (or, better, a page boundary). But yes, a very good idea.
That has the very nice side effect of allowing you to edit the command line with a text editor provided you don't cross the sector boundary. Filling with spaces would be pretty nice.

Its a bad idea.  Either have a line terminated file, or a pure binary
file, but don't mix them.  Besides firing up an editor to modify it
being a royal pain, mystery breakages will occur when someone has their
editor set to "insert mode" (which is the default) vs "overwrite mode"
and doesn't notice those extra spaces moving beyond the 512-byte mark.


Assuming that you have a tool that edits the command line (I admit, using emacs is a bad idea), then aligning to a sector boundary means that you don't have to munge the data every time you update. Since most command lines will be < 512 bytes probably, this means that you can usually get away with not having to copy any data on disk which is a very good thing when you have multi-gigabyte files.


Anthony Liguori


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]