qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] the need for if=none for -drive?


From: John Snow
Subject: Re: [Qemu-devel] the need for if=none for -drive?
Date: Mon, 03 Nov 2014 14:15:11 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0



On 11/02/2014 02:21 AM, Michael Tokarev wrote:
All "modern" 2-way drive/device specifications need to explicitly
specify if=none for the drive for it to not be used in the default
ide bus implicitly.

Which behave like this? I am reasonably sheltered in the IDE and S/ATA lands.

But how about using some if=unspecified implicitly for all devices
which don't specify if=, pick any devices from that list which are
referenced from -device, and only add those which left (plus the
ones with explicit if=ide) to the default ide bus?

I wouldn't really be opposed to this, since making things more explicit and less mysterious with the drive sugar sounds welcome to me. I imagine you're trying to avoid the case where if= is omitted and QEMU gets to decide what it wants to do in this (highly ambiguous) case?

The change should be strighforward, the only (maybe significant)
prob I see is a need to reorder -device/-drive initialization in
vl.c.  We might pick them up in drive_check_orphaned() too.  Or,
we can walk over -devices when adding -drives with if={unspec,explicit}.

(this is a sort of a followup to 6b9e03a4e759876, "qtest/bios-tables:
Correct Q35 command line", but ofcourse it's a topic by its own).

Thanks,

/mjt


It may be a little too late, since it seemed as if defaulting to "IF_DEFAULT" always winds up getting mapped to whatever is provided by the second argument of drive_new (block_default_type) which usually winds up being machine_class->block_default_type -- which for Q35 and piix both is IDE. (Implicitly, because it never sets it. interface 0 is IF_IDE -- which makes the "true default" for if ... IDE, until it is overridden.)

Changing this behavior might break more than we fix, perhaps.

I'll leave the masterminding of fixing up the grossly broken drive sugar up to Markus, the secret architect of the recent Q35 sugar patches :>



reply via email to

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