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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.

Ian.


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