David Gibson <d...@au1.ibm.com> writes: > On Thu, Oct 18, 2012 at 08:32:54AM +0200, Alexander Graf wrote: >> >> >> On 18.10.2012, at 03:18, Benjamin Herrenschmidt <b...@kernel.crashing.org> >> wrote: >> >> > On Thu, 2012-10-18 at 11:09 +1100, David Gibson wrote: >> > >> >>>> That's horrible; if you use -boot just once it will clobber a >> >>>> persistent NVRAM's boot order. I see that a means of changing the >> >>>> default boot order from management tools is desirable, but that >> >>>> shouldn't be the normal behaviour of -boot. And the objections to (2) >> >>>> apply even more strongly - we'd need to translate arbitrary -boot >> >>>> strings to NVRAM representation which may not be at all >> >>>> straightforward from the information qemu has available. >> >>> >> >>> It may not be straight forward, but it's what makes the most sense from >> >>> a user's PoV. >> >> >> >> Bollocks. Using -boot to override the normal boot sequence >> >> permanently changing the normal boot sequence absoultely does not make >> >> sense from a user's PoV. >> > >> > I strongly agree with David here. -boot should not change the persistent >> > state. >> >> I think Anthony and you are looking at 2 different use cases, each >> with their own sane reasoning. >> >> You want to have the chance to override the boot order temporarily >> for things like cd boot or quick guest rescue missions. >> >> You also want to be able to permanently change the guest's boot >> order from a management tool. At that same place you want to be able >> to display it, so you don't have to boot your vm to know what it >> would be doing. > > That's true to an extent. However, I vehemently disagree that it's > arbitrary which one gets the new option. Neither -boot nor bootindex= > alter any persistent data now and they should not suddenly start doing > so.
That's not true. For the PC, -boot modifies the CMOS memory. If we persisted CMOS, then -boot would cause a persistent modification in the boot order. Regards, Anthony Liguori
