From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages] Date: Mon, 18 Jan 2016 08:55:06 +0000 Message-ID: <569CA86A.3070102@citrix.com> References: <1452783526-29173-1-git-send-email-cardoe@cardoe.com> <1452781693-28525-1-git-send-email-cardoe@cardoe.com> <569778BE02000078000C69D4@prv-mh.provo.novell.com> <1452771751.2185.33.camel@citrix.com> <5697A78902000078000C6BAA@prv-mh.provo.novell.com> <1452779824.2185.37.camel@citrix.com> <22167.52354.193878.785231@mariner.uk.xensource.com> <1452877572.6020.85.camel@citrix.com> <5699374102000078000C782F@prv-mh.provo.novell.com> <56992B30.40500@citrix.com> <1452879727.6020.98.camel@citrix.com> <569CA72902000078000C7C4C@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <569CA72902000078000C7C4C@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Ian Campbell Cc: osstest-admin@xenproject.org, Ian Jackson , Doug Goldstein , xen-devel , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 18/01/2016 07:49, Jan Beulich wrote: >>>> On 15.01.16 at 18:42, 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, 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. 3 is required to unblock OSSTest and needs to happen ASAP. That is the absolute priority at this point. ~Andrew