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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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.

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

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

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

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

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

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