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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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