Re: [Libvir] Supporting new Xen 3.0.3 blktap backend for file devices

On Wed, Sep 27, 2006 at 01:16:17PM -0400, Daniel Veillard wrote: > On Wed, Sep 27, 2006 at 07:05:38PM +0200, Karel Zak wrote: > > On Tue, Sep 26, 2006 at 08:08:33PM +0100, Daniel P. Berrange wrote: > > > > > > This means the easy option of just making all file devices use blktap in > > > 3.0.3 is not practical. This in turns means we need to come up with a > > > way to express the new driver methods in libvirt XML. There are a few > > > options I can think of : > > > > > > - Allow more values in the 'type' attribute, eg file, block, blktap:aio, > > > blktap:qcow, etc. This feels wrong because the blktap:* entries are > > > really still 'file' types. > > > > > > - Introduce a new attribute 'driver' where you can specify 'loop', > > > 'blktap:aio', 'blktap:qcow', etc > > > > > > - Introduce a new element 'driver' where you can specify the same > > > > > > <disk type="file"> > > > <driver type='blktap:aio'/> > > > </disk> > > > > > > - Same as above, but normalize the driver type further > > > > > > <disk type="file"> > > > <driver type='blktap' backend='aio' /> > > > </disk> > > > > > > My preference is probably option 3 or 4. > > > > My preference is definitely 4. > > > > (well, I'm affected by Database Normalization where it's bad merge > > two information into one attribute -- so 'blktap:aio' is wrong way > > ;-) > > I would agree that rather than glueing it's better to separate the 2 strings > as separate attributes. But should the second be named 'backend' or something > more generic like 'subtype'. That's the only slight concern I have but it's > probably better to be explicit about and the suggested form is just fine. > Let's go for 4/ :-) Ok, looks like we have total agreement. I'll knock up a patch implementing option #4 and post it for review.