On Fri, Oct 19, 2012 at 10:40:45AM +0200, Alexander Graf wrote:
>
>
> On 19.10.2012, at 10:24, David Gibson <d...@au1.ibm.com> wrote:
>
> > 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.
> >
> > Now a method of externally altering the firmware persistent boot order
> > would certainly be nice to have. However, I'm not at all convinced
> > that it's realistically possible to do that in way that has a platform
> > neutral interface. The fundamental problem here is that we're tied to
> > the pre-existing ways the platform stores the boot order information
> > and what that's even capable of expressing can be very different from
> > platform to platform: can it express an arbitrary list, or just a
> > limited number of devices, or just one? can it represent arbitrary
> > devices in some firmware id/address scheme, or does it just
> > give order of a fixed set of known devices? or is it even more
> > limited, containing just a few "CD before disk" type booleans? for
> > that matter, does the firmware even have any notion at all of a
> > persistent configurable boot order?
>
> You get 2 lists from machine specific code:
>
> - potentially available boot devices
> - current boot order list
>
> Both lists contain a number of stringsy the mapping of those strings
> to platform specific data is responsibility of the platform. After
> all, the platform gave us the list of available devices, so it
> better accepts them in the boot order list.
Um... I'm having a lot of trouble parsing this. What is the "You"
here, and what are you counting as the "platform".
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
