Re: [Xen-devel] [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.01.16 at 10:41, <ian.campbell@xxxxxxxxxx> wrote:
> On Mon, 2016-01-18 at 00:49 -0700, Jan Beulich wrote:
>> > > > On 15.01.16 at 18:42, <ian.campbell@xxxxxxxxxx> wrote:
>> > On Fri, 2016-01-15 at 17:24 +0000, Andrew Cooper wrote:
>> > > On 15/01/16 17:15, Jan Beulich wrote:
>> > > > > > > On 15.01.16 at 18:06, <ian.campbell@xxxxxxxxxx> wrote:
>> > > > > On Thu, 2016-01-14 at 16:27 +0000, Ian Jackson wrote:
>> > > > > >  * I don't have a clear design proposal for the above but I
>> > > > > > think Doug
>> > > > > >    can probably provide one.  I'm hoping this is more a matter
>> > > > > > of
>> > > > > >    thinking carefully than of extensive build system
>> > > > > > programming!
>> > > > > I think we should:
>> > > > > 
>> > > > > 1) Move /usr/lib/debug/xen-4.7-unstable.config to /boot. I
>> > > > > previously
>> > > > > didn't care about what path it was, but the usecase of having
>> > > > > grub be able
>> > > > > to react to the config (see below) is a strong reason to have it
>> > > > > in /boot
>> > > > > IMHO. Jan has said he won't veto such a change, AFAICT everyone
>> > > > > else is
>> > > > > happy with it.
>> > > > > 
>> > > > > 2) Assume that grub (specifically the patch in http://savannah.gn 
>> > > > > u.org/bugs 
>> > > > > /?43420 and as used by osstest today) will at some point be
>> > > > > modified to
>> > > > > look at /boot/xenconfig-$version to decide whether to create an
>> > > > > XSM entry
>> > > > > or not instead of the presence of /boot/xenpolicy-$version. This
>> > > > > step
>> > > > > belongs here logically but chronologically could come much later
>> > > > > since
>> > > > > osstest will do the right thing even if there is a spurious
>> > > > > /boot/xenpolicy-$version file (which is to say it will ignore the
>> > > > > spurious
>> > > > > entry and boot the right thing).
>> > > > > 
>> > > > > 3) Have tools/* always build the FLASK+XSM tools _and_ the FLASK
>> > > > > policy and
>> > > > > to always install both. Any related configure options can go away
>> > > > > and we no
>> > > > > longer need to worry about synchronising the configuration of the
>> > > > > tools and
>> > > > > xen trees, this is desirable because we would prefer to have one
>> > > > > set of
>> > > > > tools which gracefully handles differing hypervisor
>> > > > > configurations over
>> > > > > needing different sets of tools (FLASK+XSM was one of the few
>> > > > > exceptions to
>> > > > > that rule AFAICT).
>> > > > > 
>> > > > > I think with this plan there is no need to modify osstest.git,
>> > > > > since it
>> > > > > already does the right thing (which is, it sets XSM for Xen
>> > > > > builds, which
>> > > > > in turn enables FLASK and it does nothing for tools/* which is
>> > > > > correct once
>> > > > > #3 above has happened).
>> > > > > 
>> > > > > The only downside is a spurious /boot/xenpolicy-$version
>> > > > > installed when the
>> > > > > corresponding Xen binary doesn't support XSM, however given the
>> > > > > assumption
>> > > > > in #2 (which implies the user will never see a spurious grub
>> > > > > entry, which
>> > > > > is the important thing) and the fact that it avoids the
>> > > > > complexity of
>> > > > > having tools/* rely in some way on xen/.config I think that is a
>> > > > > worthwhile
>> > > > > trade-off.
>> > > > > 
>> > > > > Hopefully this simplifies a bunch of the arguments we have been
>> > > > > having and
>> > > > > provides a path forwards?
>> > > > > 
>> > > > > Objections?
>> > > > My opinion on 1 and 2 is known; 3 seems like a good step to me.
>> > > 
>> > > FWIW, I also prefer option 3.  It lends itself better to a toolstack
>> > > which functions in the same way, irrespective of hypervisor
>> > > configuration.
>> > 
>> > To be clear: These are not options, they are steps in a plan, to be
>> > followed in order.
>> 
>> "Not options" - indeed, but "in order"? At least 3 seems independent
>> of both 1 and 2.
> 
> Without #1 we cannot make the assumption in #2.
> 
> Without (the assumption of eventually doing) #2 we cannot do #3 because
> that would result in spurious boot menu entries for users (i.e. ones which
> claim to enable XSM but boot an XSM incapable Xen) which several of us feel
> we should avoid.

Ugly. Could we live with that until #1 and #2 get put in place?
Otherwise it looks very much like reverting the two Kconfig
conversion patches is the only possible solution at this point...

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel