| Message ID | 1452107994-2681-1-git-send-email-cardoe@cardoe.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 >
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 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.
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
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(+)