[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]
>>> On 18.01.16 at 10:41, <ian.campbell@xxxxxxxxxx> wrote: > 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. Ugly. Could we live with that until #1 and #2 get put in place? Otherwise it looks very much like reverting the two Kconfig conversion patches is the only possible solution at this point... Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |