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