Re: [Xen-devel] Kbuild and Kconfig

[Doug Goldstein <cardoe@xxxxxxxxxx>]

On 9/3/15 4:56 AM, Tim Deegan wrote:
> Hi,
> 
> At 12:50 -0500 on 02 Sep (1441198200), Doug Goldstein wrote:
>> I just wanted to bring this to a top level post since Jonathan Creekmore
>> and myself have talked with a few maintainers in different threads and
>> on IRC about potentially using Kconfig and/or Kbuild for Xen.
> 
> If we're going to need a configure step before building the
> hypervisor, maybe we should consider using the autoconf runes instead.
> 
> I'm one of the people who objected to requiring ./configure before
> building the hypervisor, but I think it would be better than having
> _two_ config systems which are not synced with each other, esp. if
> we'll want to enable/disable features with matching tools-side code.
> 
> If we do go this way, I think we'd need a ./configure --hypervisor-only,
> or similar, that _only_ makes the various CONFIG_ flags, and doesn't
> do the tedious library & compiler checks that are needed for the
> user-space code.
> 
> Cheers,
> 
> Tim.
> 

I'd only be concerned about the fact that different config switches
would do different things and you would end up with a lot of configure
switches.

e.g. ./configure --with-kexec --without-xenlinux --with-xsm

Currently there is a top level XSM_ENABLE and FLASK_ENABLE and they do
different things in the tools/ and the xen/ directories. For the tools
directory all it does is disable the Flask policy being built (e.g.
XSM_ENABLE=n does that) while XSM bits in the tools appear to always be
built. Then for the xen/ directory XSM_ENABLE=n will actually turn off
XSM support and Flask support while FLASK_ENABLE=n will keep XSM on and
just build the dummy XSM module.

You may also have cases where you want to build functionality into the
tools but not into the hypervisor to ensure that the hypervisor returns
an error and the tools gracefully handle that case which having a top
level configure script would make more difficult.

-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

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