Re: [Xen-devel] [xen-unstable test] 77945: regressions - FAIL [and 2 more messages]

[Doug Goldstein <cardoe@xxxxxxxxxx>]

On 1/14/16 10:27 AM, Ian Jackson 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

I think this is where the issue lies. There have always been multiple
switches to pull and different assumptions where made.

- XSM in the hypervisor was enabled by XSM_ENABLE at the top level.
Currently it is enabled by the CONFIG_XSM Kconfig switch in the xen/
directory.
- FLASK in the hypervisor was enabled by FLASK_ENABLE at the top level.
It did not depend on XSM_ENABLE in the Makefile rules (but the code did
ifdef it out since it needed XSM_ENABLE). Currently it is enabled by the
CONFIG_FLASK Kconfig switch in the xen/ directory. It depends on CONFIG_XSM.
- The FLASK policy installation is controlled in the tools/ by
--enable-xsmpolicy (which is the default) however the policy COULDN'T
build without FLASK_ENABLE being set at the top level but you could
disable XSM_ENABLE and it would still build. (which is what my patch
tried to make more explicit in osstest)
- Xen+XSM boot entry doesn't exist today but with storing the state of
the hypervisor in the .config we'll be able to make this smart by saying
"Xen supports FLASK so load in the policy since the policy is present"

> 
>  * 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.

That's fine but we need to make the pull switch explicitly set all the
knobs correctly and not rely on implicit defaults.

> 
>  * This single handle should be used by osstest, so that osstest is
>    testing the most usual build method.  (Corollary: current code in
>    osstest that conditionally copies the policy is a bodge which would
>    ideally go away.)

Will it be if we document it that people need to provide a Kconfig file
to enable it and then configure with --enable-xsmpolicy?

> 
>  * I do not have a strong opinion about whether FLASK policy-handling
>    tools ought to be always built.  I see no harm in building them
>    always and I can see arguments in favour.
> 
>  * Users should not get boot config options that are definitely not
>    going to work (see above).  (Or at least, not unless they try
>    hard.)

I agree and that's more likely to happen now with the Kconfig file being
saved.

> 
>  * 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.

So that was my question early on in the Kconfig bits if it the .config
bits should drag up to the top level or just be contained into xen/ and
I was told to keep it in xen/ hence for the split.

> 
>  * 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.

I'm not sure of the best approach here. It will require a little bit of
tinkering.

> 
>  * 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 agree with you. But Jan disagreed. I submitted a patch both ways
because progress was better than bikeshedding and he merged the patch
into /usr/lib/debug. I'd be in favor of seeing it moved to /boot.

> 
>  * osstest's replacement Xen grub menu entry generator ought to be on
>    an upstream track.  This is necessary because osstest ought to be
>    using features that users will get too.

I agree here as well. I've got a few patches that I'm planning on
submitting to grub as well to make the options a little clearer and the
defaults do the right thing in more cases.

> 
>  * 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!
> 
>  * If a fix for this is hard to achieve for some reason I will be
>    content with patches which make things no worse, overall, than they
>    were before Christmas :-).  (By which I do not mean that I demand a
>    Pareto improvement.)
> 
> Is any of this of any use ?
> 
> Thanks,
> Ian.
> (no less confused after writing this than I was before)
> 

The take away I see here is whatever path is taken we just need to be a
bit more explicit with what does what or what is called what to avoid
potential breakages.

-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel