[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specifica
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification |
Date: |
Tue, 12 Oct 2010 14:16:40 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
On Tue, Oct 12, 2010 at 10:07:53AM +0200, Kevin Wolf wrote:
> Am 11.10.2010 19:14, schrieb Anthony Liguori:
> > On 10/11/2010 11:18 AM, Anthony Liguori wrote:
> >> On 10/11/2010 10:46 AM, Stefan Hajnoczi wrote:
> >>> On Mon, Oct 11, 2010 at 05:39:01PM +0200, Avi Kivity wrote:
> >>>> On 10/11/2010 05:30 PM, Stefan Hajnoczi wrote:
> >>>>>> It was discussed before, but I don't think we came to a
> >>>>>> conclusion. Are
> >>>>>> there any circumstances under which you don't want to set the
> >>>>>> QED_CF_BACKING_FORMAT flag?
> >>>>> I suggest the following:
> >>>>>
> >>>>> QED_CF_BACKING_FORMAT_RAW = 0x1
> >>>>>
> >>>>> When set, the backing file is a raw image and should not be probed for
> >>>>> its file format. The default (unset) means that the backing image
> >>>>> file
> >>>>> format may be probed.
> >>>>>
> >>>>> Now the backing_fmt_{offset,size} are no longer necessary.
> >>>> Should it not be an incompatible option? If the backing disk starts
> >>>> with a format magic, it will be probed by an older qemu,
> >>>> incorrectly.
> >>> Agreed, it should be a non-compat feature bit.
> >>
> >> If it's just raw or not raw, then I agree it should be non-compat.
> >>
> >> I think we just need a feature bit then that indicates that the
> >> backing file is non-probeable which certainly simplifies the
> >> implementation.
> >>
> >> QED_F_BACKING_FORMAT_NOPROBE maybe?
> >
> > Er, thinking more, this is still a good idea but we still need
> > QED_CF_BACKING_FORMAT because we specifically need to know when a
> > protocol is specified. Otherwise, we have no way of doing nbd as a
> > backing file.
>
> Well, the protocol is currently encoded in the file name, separated by a
> colon. Of course, we want to get rid of that, but we still don't know
> what we want instead. It's completely unrelated to the backing file
> format, though, it's about the format of the backing file name.
I agree with Kevin. There's no need to have the ill-defined backing
format AFAICT.
Stefan
- Re: [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification, (continued)
[Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification, Kevin Wolf, 2010/10/11
- [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification, Stefan Hajnoczi, 2010/10/11
- [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification, Avi Kivity, 2010/10/11
- [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification, Stefan Hajnoczi, 2010/10/11
- Re: [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification, Anthony Liguori, 2010/10/11
- Re: [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification, Anthony Liguori, 2010/10/11
- Re: [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification, Kevin Wolf, 2010/10/12
- Re: [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification,
Stefan Hajnoczi <=
- Re: [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification, Anthony Liguori, 2010/10/12
[Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification, Kevin Wolf, 2010/10/11
[Qemu-devel] [PATCH v2 4/7] qed: Add QEMU Enhanced Disk image format, Stefan Hajnoczi, 2010/10/08
[Qemu-devel] [PATCH v2 6/7] qed: Read/write support, Stefan Hajnoczi, 2010/10/08