qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 03/10] S390: Check Bootdevice Type


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 03/10] S390: Check Bootdevice Type
Date: Fri, 26 Apr 2013 18:13:02 +0200

On 26.04.2013, at 18:10, Dominik Dingel wrote:

> On Fri, 26 Apr 2013 18:05:02 +0200
> Alexander Graf <address@hidden> wrote:
> 
>> 
>> On 26.04.2013, at 18:01, Christian Borntraeger wrote:
>> 
>>> On 26/04/13 17:48, Alexander Graf wrote:
>>> 
>>>>> So I suggest to go with this patch and implement later on what we
>>>>> agree upon?
>>>> 
>>>> I don't see how having "first device we find" is any better than a 
>>>> rushed interface we need to agree on right before 1.5 hard freeze. 
>>> 
>>> Exactly, find first device isnt better ;-)
>>> See, the current code chooses the first subchannel that matches. This
>>> boils down to "a random disk" as soon as you have more than one.
>>> 
>>> With this patch the user can at least specify the devno of the disk.It
>>> even works out of the box with libvirt.
>>> 
>>> Let's just release 1.5 with the very simple one and then go for something 
>>> awesome in the next version.
>>> 
>>> Exactly - and having a list is more in the awesome area. Beiing able to
>>> specify the first disk and pass that in a register to the bios is of
>>> course not a full-features interface, but it works and can be changed.
>> 
>> My main concern is backwards compatibility. If we introduce a command line 
>> interface now, we have to support it forever. I'd rather only support one 
>> interface, rather than 2 out of which one is only legacy for 1.5 
>> compatibility.
> 
> We only enable, don't introduce the existing command line interface for 
> bootindex. The loadparm thing is already kind of list, as the loadparm is 
> stored with every device. 
> But as I wrote in the cover letter, we also could just for the start only 
> implement the bootindex.  

The bootindex is the part that I'm reluctant about. I think it's the right way 
forward, but it touches generic code and generic infrastructure a few days 
before hard freeze. I don't think it's important enough to justify this.


Alex




reply via email to

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