[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 14.01.16 at 17:27, <Ian.Jackson@xxxxxxxxxxxxx> wrote: > I have to confess I'm quite confused now. Maybe there are many > underlying disagreements here but mostly I seem befogged. However, > here are some principles I currently believe in for how this should > all work: > > * It should be possible to enable, or disable, all of the following > things by pulling one handle: > - XSM hypervisor support > - FLASK hypervisor support > - installation of the FLASK policy in /boot > - presence of the Xen+XSM boot entry > > * FAOD it is IMO OK for some of those things to be configurable > separately, but there should be one most obvious way to enable, or > disable, them all together. Both of these would be nice, but I don't view this a requirement. > * Users should not get boot config options that are definitely not > going to work (see above). (Or at least, not unless they try > hard.) Agreed. > * The hypervisor maintainers object to autoconf. This is fine. But > it means that if we want to have a single configuration option > which affects both hypervisor and tools (at least, by default), > that it should be possible for tools config options to at least > inherit their defaults from Kconfig. > > * Perhaps this should be done by having the tools configure run some > Kconfig. If so there should be an autoconf command line option to > suppress this. > > * Alternatively, perhaps configure should be changed so that it can > set Kconfig settings which the hypervisor build will pick up. All of these fall into the same area as the first two above - would be nice, but not strict requirement. In particular with the various subtrees there's no requirement for both tools and hypervisor to be built at all in the same tree. (In fact on my only left 32-bit host this is what happens - the 32-bit build tree only gets tools built, and the 64-bit build tree only gets the hypervisor built.) > * IMO it is fine to put the Xen Kconfig config file in /boot. Given > the existing state of the rest of the universe, this seems like the > best place for me. I continue to disagree, but I wouldn't outright veto someone else committing a change to this effect. I won't, however, commit such a change myself (or only with an Explicitly-not-acked-by: tag). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |