From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: [xen-unstable test] 77945: regressions - FAIL [and 2 more messages] Date: Fri, 15 Jan 2016 11:21:41 -0600 Message-ID: <56992AA5.5040605@cardoe.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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6095983517172249688==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aK84M-0007dq-Kj for xen-devel@lists.xenproject.org; Fri, 15 Jan 2016 17:21:50 +0000 Received: by mail-yk0-f180.google.com with SMTP id a85so472331704ykb.1 for ; Fri, 15 Jan 2016 09:21:48 -0800 (PST) In-Reply-To: <1452877572.6020.85.camel@citrix.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: Ian Campbell , Ian Jackson Cc: xen-devel , osstest-admin@xenproject.org, Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============6095983517172249688== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rU5d6Dug1NEnKEMCRw7GkjbkkAm0DS0h3" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rU5d6Dug1NEnKEMCRw7GkjbkkAm0DS0h3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/15/16 11:06 AM, Ian Campbell 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! >=20 > I think we should: >=20 > 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 a= ble > to react to the config (see below) is a strong reason to have it in /bo= ot > IMHO. Jan has said he won't veto such a change, AFAICT everyone else is= > happy with it. >=20 > 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 ent= ry > 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 spuri= ous > entry and boot the right thing). >=20 > 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 w= e 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 exception= s to > that rule AFAICT). >=20 > 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, whi= ch > in turn enables FLASK and it does nothing for tools/* which is correct = once > #3 above has happened). >=20 > The only downside is a spurious /boot/xenpolicy-$version installed when= the > corresponding Xen binary doesn't support XSM, however given the assumpt= ion > in #2 (which implies the user will never see a spurious grub entry, whi= ch > 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 worthw= hile > trade-off. >=20 > Hopefully this simplifies a bunch of the arguments we have been having = and > provides a path forwards? >=20 > Objections? >=20 > Doug, I think you have the majority of #1 and #3 already in some form o= r > other? #2 is not on the critical path and can come later. >=20 > Ian. >=20 Yes. No objections here. Yes I've submitted a patch for #1 and #3 earlier. They'll need to be rebased but that's easy. --=20 Doug Goldstein --rU5d6Dug1NEnKEMCRw7GkjbkkAm0DS0h3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWmSqoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUQh8P/3JKSe3/bOwNNAwCRO6rCuWa BuBf7uHJgropl3CWYe7wobI8hqXCO8CJ+Xkb4fx7QiqWYBUaLl36RCkI/zEml2qc DWbHo9O8/16PDeAghAQig6KggPclTqN7cik5jx/cHnFL3vo8avgZFzx+yOHDW/x7 Whe2xMEhCw/ySOVpHsyPYoiSItWmcPYyc569GzuawdofPvWaiCaHh7VFtZkcj6uB OvYw9taqaIb+lmBUvDk1lwpYdDGyt9tjmwm+JvsWipxu04A5J+qG4k/Pkhz4I2TG W7Mv6gURpW8wXOso1ri8zoKAN/m6r66DeAkPP6TfeaWbfAjHSwbzlJNA7sDiqcx/ VpH3FZwG72fRp6AMvyaTG+JBcbu4zgPuaIysrvsqnx3XA+KdI4g8Bd2E9n9V4HWp 15XPEjNnHCkOnqq3MwO42VkWPs57UaPV8k4sk57NVvSInVpD8ppvDItHRpTONobm sJ0uRwwg+6G3WFtZ4ARxk2IvTwwZp9/9JB5QhbUbkkZ2avUh9Qq3iyhCAZHKGx6o MIuLIM5x+hiIK6qFT7bhZJbSfvwzOxZiFXP4n1R5VVIO3ySQOr6IGfOfrUg/oywb KhU402BYCY7cEdm8Fh4AbIphq+wnkO8U5svecuJhJmMWBkJ6QfNz4b0TrShinatZ CvA421wI6hnBR3nIT3hz =Ieqx -----END PGP SIGNATURE----- --rU5d6Dug1NEnKEMCRw7GkjbkkAm0DS0h3-- --===============6095983517172249688== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6095983517172249688==--