* [LTP] How to build LTP for a kernel different than the one on the building machine?
@ 2018-05-15 3:29 Zhang, Yixin
2018-05-15 10:41 ` Cyril Hrubis
0 siblings, 1 reply; 3+ messages in thread
From: Zhang, Yixin @ 2018-05-15 3:29 UTC (permalink / raw)
To: ltp
Hello,
I'm trying to run LTP in my test environment, after some investigation I've one question on the building processes of LTP. When building some of the test cases binary, it need to access the kernel header, some of which may changes between different kernel version. So is there a way to build LTP on the building machine with kernel, say v4.14, for a test machine with test target v4.16?
In the configure file I see below line about "--with-linux-dir" and "LINUX_DIR":
6280 # Check whether --with-linux-dir was given.
6281 if test "${with_linux_dir+set}" = set; then :
6282 withval=$with_linux_dir; LINUX_DIR="${withval}"
6283 else
6284 if test -n "$LINUX_VERSION"; then :
6285 LINUX_DIR="/lib/modules/$LINUX_VERSION/build"
6286 fi
6287 fi
And "LINUX_DIR" is used in and only in "include/mk/module.mk":
56 %.ko: %.c .dep_modules ;
57
58 .dep_modules: $(MODULE_SOURCES)
59 @echo "Building modules: $(MODULE_SOURCES)"
60 -$(MAKE) -C $(LINUX_DIR) M=$(abs_srcdir)
61 rm -rf *.mod.c *.o *.ko.unsigned modules.order .tmp* .*.ko .*.cmd Module.symvers
62 @touch .dep_modules
So the question is, beside kernel module, is there any other cases also need kernel headers? If there is, or I want to add some cases which is sensitive to kernel header version, how should I create a Makefile for that? And how should I build such a test binary when the building machine has a kernel version different than the test machine?
Thanks all:)
Yixin
^ permalink raw reply [flat|nested] 3+ messages in thread
* [LTP] How to build LTP for a kernel different than the one on the building machine?
2018-05-15 3:29 [LTP] How to build LTP for a kernel different than the one on the building machine? Zhang, Yixin
@ 2018-05-15 10:41 ` Cyril Hrubis
2018-05-16 9:53 ` Zhang, Yixin
0 siblings, 1 reply; 3+ messages in thread
From: Cyril Hrubis @ 2018-05-15 10:41 UTC (permalink / raw)
To: ltp
Hi!
> I'm trying to run LTP in my test environment, after some investigation
> I've one question on the building processes of LTP. When building some
> of the test cases binary, it need to access the kernel header, some of
> which may changes between different kernel version. So is there a way
> to build LTP on the building machine with kernel, say v4.14, for a
> test machine with test target v4.16?
Pointing the LINUX_DIR to a directory with v4.14 compiled kernel should
work, the LTP build system would make use of the kernel build system to
build the modules for us.
However most of the modules we have in LTP tend to fail to compile on
newer kernels, which is ignored by the build system. The problem is that
kernel API changes quite often and we fail to keep up with that.
> In the configure file I see below line about "--with-linux-dir" and "LINUX_DIR":
> 6280 # Check whether --with-linux-dir was given.
> 6281 if test "${with_linux_dir+set}" = set; then :
> 6282 withval=$with_linux_dir; LINUX_DIR="${withval}"
> 6283 else
> 6284 if test -n "$LINUX_VERSION"; then :
> 6285 LINUX_DIR="/lib/modules/$LINUX_VERSION/build"
> 6286 fi
> 6287 fi
>
> And "LINUX_DIR" is used in and only in "include/mk/module.mk":
> 56 %.ko: %.c .dep_modules ;
> 57
> 58 .dep_modules: $(MODULE_SOURCES)
> 59 @echo "Building modules: $(MODULE_SOURCES)"
> 60 -$(MAKE) -C $(LINUX_DIR) M=$(abs_srcdir)
> 61 rm -rf *.mod.c *.o *.ko.unsigned modules.order .tmp* .*.ko .*.cmd Module.symvers
> 62 @touch .dep_modules
>
> So the question is, beside kernel module, is there any other cases
> also need kernel headers?
I doubt so.
> If there is, or I want to add some cases which is sensitive to kernel
> header version, how should I create a Makefile for that? And how
> should I build such a test binary when the building machine has a
> kernel version different than the test machine?
That depends on what you are trying to do, generally we do prefer
runtime detection whenever possible.
Can you explain what kind of test are trying to develop?
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 3+ messages in thread
* [LTP] How to build LTP for a kernel different than the one on the building machine?
2018-05-15 10:41 ` Cyril Hrubis
@ 2018-05-16 9:53 ` Zhang, Yixin
0 siblings, 0 replies; 3+ messages in thread
From: Zhang, Yixin @ 2018-05-16 9:53 UTC (permalink / raw)
To: ltp
Hi Cyril,
Actually here we have a small team trying to develop test cases based on the LTP
framework to test some pre-release features in internal kernel tree (also we are
seeking the possibility to upstream related test cases when related kernel feature
is upstreamed to mainline kernel, which is a seperate topic). For some tests we
need to build a kernel module to test from kernel space, and for some other
tests we need to build test binary with kernel header files which is changing
frequently as the kernel feature itself is still under development.
From the test exection side, we are building all LTP packages on a server with
Jenkins (and with a relative old kernel like 4.10) for all test targets
(differnt HWs and different latest kernel versions). Some test targets are
simulators so it'll be almost impossible to build LTP on the same test target.
So I need to figure out how to build LTP when the build machine have a kernel
different than the test target machine.
I'll try the "--with-linux-dir" and see if it work for my situation. Thanks.
Yixin
On 2018-05-15 at 12:41:48 +0200, Cyril Hrubis wrote:
> Hi!
> > I'm trying to run LTP in my test environment, after some investigation
> > I've one question on the building processes of LTP. When building some
> > of the test cases binary, it need to access the kernel header, some of
> > which may changes between different kernel version. So is there a way
> > to build LTP on the building machine with kernel, say v4.14, for a
> > test machine with test target v4.16?
>
> Pointing the LINUX_DIR to a directory with v4.14 compiled kernel should
> work, the LTP build system would make use of the kernel build system to
> build the modules for us.
>
> However most of the modules we have in LTP tend to fail to compile on
> newer kernels, which is ignored by the build system. The problem is that
> kernel API changes quite often and we fail to keep up with that.
>
> > In the configure file I see below line about "--with-linux-dir" and "LINUX_DIR":
> > 6280 # Check whether --with-linux-dir was given.
> > 6281 if test "${with_linux_dir+set}" = set; then :
> > 6282 withval=$with_linux_dir; LINUX_DIR="${withval}"
> > 6283 else
> > 6284 if test -n "$LINUX_VERSION"; then :
> > 6285 LINUX_DIR="/lib/modules/$LINUX_VERSION/build"
> > 6286 fi
> > 6287 fi
> >
> > And "LINUX_DIR" is used in and only in "include/mk/module.mk":
> > 56 %.ko: %.c .dep_modules ;
> > 57
> > 58 .dep_modules: $(MODULE_SOURCES)
> > 59 @echo "Building modules: $(MODULE_SOURCES)"
> > 60 -$(MAKE) -C $(LINUX_DIR) M=$(abs_srcdir)
> > 61 rm -rf *.mod.c *.o *.ko.unsigned modules.order .tmp* .*.ko .*.cmd Module.symvers
> > 62 @touch .dep_modules
> >
> > So the question is, beside kernel module, is there any other cases
> > also need kernel headers?
>
> I doubt so.
>
> > If there is, or I want to add some cases which is sensitive to kernel
> > header version, how should I create a Makefile for that? And how
> > should I build such a test binary when the building machine has a
> > kernel version different than the test machine?
>
> That depends on what you are trying to do, generally we do prefer
> runtime detection whenever possible.
>
> Can you explain what kind of test are trying to develop?
>
> --
> Cyril Hrubis
> chrubis@suse.cz
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-05-16 9:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-15 3:29 [LTP] How to build LTP for a kernel different than the one on the building machine? Zhang, Yixin
2018-05-15 10:41 ` Cyril Hrubis
2018-05-16 9:53 ` Zhang, Yixin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.