[OSSTEST PATCH v3] support XSM/FLASK via Kconfig

[OSSTEST PATCH v3] support XSM/FLASK via Kconfig

[Doug Goldstein]

In antcipation of XSM and FLASK migrating to Kconfig add support for
building them via Kconfig or the existing mechanism.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
---
Still untested but visually looks correct.

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}'
+	fi
 	echo >>.config XSM_ENABLE='${build_xsm}'
 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
 
-- 
2.4.10

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

[Ian Campbell]

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@cardoe.com>
> ---
> 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.

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.

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.

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

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

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

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 2666 bytes --]

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@cardoe.com>
>> ---
>> 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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Ian Jackson]

Doug Goldstein writes ("[OSSTEST PATCH v3] support XSM/FLASK via Kconfig"):
> In antcipation of XSM and FLASK migrating to Kconfig add support for
> building them via Kconfig or the existing mechanism.
> 
> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
> ---
> Still untested but visually looks correct.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

I think I am happy to throw this into the osstest push gate without
further ad-hoc testing.

Ian.