Re: [Xen-devel] [OSSTEST PATCH v3] support XSM/FLASK via Kconfig

[Doug Goldstein <cardoe@xxxxxxxxxx>]

On 1/7/16 4:04 AM, Ian Campbell wrote:
> On Wed, 2016-01-06 at 13:19 -0600, Doug Goldstein wrote:
>> In antcipation of XSM and FLASK migrating to Kconfig add support for
> 
> "anticipation"
> 
>> building them via Kconfig or the existing mechanism.
>>
>> Signed-off-by: Doug Goldstein <cardoe@xxxxxxxxxx>
>> ---
>> Still untested but visually looks correct.
> 
> To me as well. I have a couple of questions though.
> 
>> Changes since v3:
>> - Wrap all hunks of code with checks for Kconfig to not dirty the tree
>>
>> Changes since v2:
>> - Support Xen versions prior to Kconfig being integrated
>> ---
>>  ts-xen-build | 7 +++++++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/ts-xen-build b/ts-xen-build
>> index 80b1faa..bc4e41a 100755
>> --- a/ts-xen-build
>> +++ b/ts-xen-build
>> @@ -55,6 +55,10 @@ sub checkout () {
>>      echo >>.config KERNELS=''
>>  END
>>                 (nonempty($r{enable_xsm}) ? <<END : '').
>> +    if test -f xen/Kconfig; then
>> +            echo >>xen/.config CONFIG_XSM='${build_xsm}'
>> +            echo >>xen/.config CONFIG_FLASK='${build_xsm}'
> 
> These are meaningless in a tree which has Kconfig but not yet the patches
> to make XSM configured that way. However the subsequent olddefconfig will
> just cause them to be dropped from the eventual .config.
> 
> Which then answers my second question which is: is this...
> 
>> +    fi
>>      echo >>.config XSM_ENABLE='${build_xsm}'
> 
> ... echo still needed if xen/Kconfig exists? The answer I think is yes
> precisely because of the window of time mention above.

yes due to the difference between Kconfig landing and XSM changing to
take advantage due to

> 
> I suppose it will be possible to detect of this echo is needed with "grep
> -q XSM_ENABLE Config.mk", but maybe that can wait for another time.

I thought it was harmless to include it so I didn't bother with the
grep. I can roll a v4 with that if you'd prefer.

> 
> Also I conclude that this osstest patch should be a blocker for the xen.git
> change, since if xen.git is patched first our XSM builds will unexpectedly
> be non-Xsm builds.

Yes.

> 
>>  END
>>                 (nonempty($r{tree_qemu}) ? <<END : '').
>> @@ -126,6 +130,9 @@ END
>>  END
>>  #/;
>>      buildcmd_stamped_logged(9000, 'build', '',<<END,'');
>> +            if test -f xen/Kconfig; then
>> +                $make_prefix make -C xen olddefconfig
>> +            fi
>>              $make_prefix make $makeflags @ARGV
>>  END
>>  

So I guess my question is do I need to roll a v4 or is this ok (save for
the spelling mistake in the commit msg).

-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

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