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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.gnu.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?

Doug, I think you have the majority of #1 and #3 already in some form or
other? #2 is not on the critical path and can come later.

Ian.

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