[Libvir] Fix handling of HVM boot parameters

[Daniel P. Berrange]

On Thu, Aug 10, 2006 at 11:37:33AM -0400, Daniel Veillard wrote:
> On Thu, Aug 10, 2006 at 04:08:30PM +0100, Daniel P. Berrange wrote:
> > Actually I take that back. There is a potentially never ending list of
> > different disk interfaces (IDE, FD, SCSI, XVDA) - I don't think we really
> > need to dstingiush between them by having separate <floppy> <disk>, <cdrom>
> > tags, since the value of the 'dev' attribute is always unique.
> 
>   Well hdc could as well be an ide disk or an ide CD-Rom or an ide 
> CD-RW. I though that the readonly element should be sufficient at the
> emulation level, but Jeremy don't think so. making new element name

<readonly> is fine if we also have 'device=cdrom' attribute because we
can reliably map back & forth with the latter. <readonly> will be needed
when the new CDROM device model appears in xen 3.0.3 because that has
space for an explicit 'mode' flag in the device SEXPR to distinguish
'r' and 'rw'.

> ain't good from an XML perspective. But we could hint at the expected
> kind of device as an extra attribute on <disk>, 
> 
>    <disk type='file' device='cdrom'>
>      <source file='/root/boot.iso'/>
>      <target dev='hdc'/>
>      <readonly/>
>    </disk>
> 
> the problem would then to maintain a list of supported device values
> the default being a disk if the attribute is ommited.

Well, HAL has a similar property is assigns to storage devices 'device_type'

http://webcvs.freedesktop.org/hal/hal/doc/spec/hal-spec.html?view=co&pathrev=HEAD#device-properties-storage

They current enumerate 'disk', 'cdrom', 'floppy', 'tape', and a bunch of
flash memory types 'compact_flash', 'memory_stick', 'smart_media','sd_mmc'
We could just adopt the first three options, and say 'disk' is default if
it is ommitted. Trying to get into finer detail like 'dvd', 'cdr', 'cdrw'
is doomed to failure because there are just soo many combinations and
many drives support many cd* variants at once. The 'disk', 'cdrom' and
'floppy' options are trivial to map to SEXPR both directions.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|