[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [OSSTEST PATCH v3] support XSM/FLASK via Kconfig
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |