[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 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! > > 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. > 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. -- Doug Goldstein Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |