Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Darren Hart <dvhart@linux.intel.com>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: RFC: Further kernel build process changes?
Date: Wed, 07 Jan 2015 21:16:03 +0000	[thread overview]
Message-ID: <1420665363.25779.73.camel@linuxfoundation.org> (raw)
In-Reply-To: <D0D2B965.B6633%darren.hart@intel.com>

On Wed, 2015-01-07 at 10:33 -0800, Darren Hart wrote:
> On 1/7/15, 5:22 AM, "Bruce Ashfield" <bruce.ashfield@windriver.com> wrote:
> >On 2015-01-07 7:26 AM, Richard Purdie wrote:
> >>
> >> External module builds do work in this configuration *if* you pass in
> >> the correct options e.g.:
> >>
> >> make -C work-shared/MACHINE/kernel-source
> >>O=work-shared/MACHINE/kernel-build M=${S}
> >>
> >> I've put together a quick proof of concept of this below.
> 
> 
> I was concerned about how this would impact hello-mod and recipes modeled
> after it, however, in reviewing the patch below, it looks to have this
> covered. I¹ll verify this just as soon as my workstation is available
> (it¹s ³busy² updatingŠ sigh).

I have not tested that yet, however it is something we need to do, if it
has issues, I think they should be solvable.

> A couple of first pass questions belowŠ prior to applying and testing
> myself...
>
> >> diff --git a/meta/classes/kernel-module-split.bbclass
> >>b/meta/classes/kernel-module-split.bbclass
> >> index 9a95b72..2d43b51 100644
> >> --- a/meta/classes/kernel-module-split.bbclass
> >> +++ b/meta/classes/kernel-module-split.bbclass
> >> @@ -70,7 +70,7 @@ python split_kernel_module_packages () {
> >>           m = kerverrexp.match(kernelver)
> >>           if m:
> >>               kernelver_stripped = m.group(1)
> >> -        staging_kernel_dir = d.getVar("STAGING_KERNEL_DIR", True)
> >> +        staging_kernel_dir = d.getVar("STAGING_KERNEL_BUILDDIR", True)
> >>           system_map_file = "%s/boot/System.map-%s" % (dvar, kernelver)
> >>           if not os.path.exists(system_map_file):
> >>               system_map_file = "%s/System.map-%s" %
> >>(staging_kernel_dir, kernelver)
> >> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> >> index 5cabc2c..b1a1ccf 100644
> >> --- a/meta/classes/kernel.bbclass
> >> +++ b/meta/classes/kernel.bbclass
> >> @@ -249,6 +249,10 @@ kernel_do_install() {
> >>   	cp .config $kerneldir/
> >>   	mkdir -p $kerneldir/include/config
> >>   	cp include/config/kernel.release
> >>$kerneldir/include/config/kernel.release
> >> +	if [ -e include/linux/version.h ]; then
> >> +		mkdir -p $kerneldir/include/linux
> >> +		cp include/linux/version.h $kerneldir/include/linux/version.h
> >> +	fi
> 
> 
> I know this bit someone with the recent changes, let¹s make sure we add a
> comment as to why this is required so we don¹t have to dig it out of the
> archives in a year when we¹re doing another round of fixes in this area.

I know Bruce is not convinced about this part yet and talked with Otavio
a little. We could do something like this:

diff --git a/meta/classes/module-base.bbclass b/meta/classes/module-base.bbclass
index c34eee7..58ec3f4 100644
--- a/meta/classes/module-base.bbclass
+++ b/meta/classes/module-base.bbclass
@@ -11,10 +11,12 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 do_configure[depends] += "virtual/kernel:do_install"
 
+EXTRA_KERNELSRC_TARGETS = ""
+
 # Function to ensure the kernel scripts are created. Expected to
 # be called before do_compile. See module.bbclass for an exmaple.
 do_make_scripts() {
 	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS 
 	make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
-	           -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} scripts
+	           -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} scripts ${EXTRA_KERNELSRC_TARGETS}
 }

and then Otavio could add EXTRA_KERNELSRC_TARGETS +=
"linux/kernel/version.h" to the two problematic recipes.

> >>   	# As of Linux kernel version 3.0.1, the clean target removes
> >>   	# arch/powerpc/lib/crtsavres.o which is present in
> >> @@ -268,6 +272,45 @@ kernel_do_install() {
> >>   }
> >>   do_install[prefuncs] += "package_get_auto_pr"
> >>
> >> +addtask do_shared_workdir after do_compile before do_install
> >> +
> >> +do_shared_workdir () {
> >> +	cd ${B}
> >> +
> >> +	kerneldir=${STAGING_KERNEL_BUILDDIR}
> >> +	install -d $kerneldir
> >> +
> >> +	#
> >> +	# Store the kernel version in sysroots for module-base.bbclass
> >> +	#
> >> +
> 
> OK, how does this impact the dependency on do_installŠ As we¹re doing
> stuff for building modules here, can that now depend on do_shared_workdir?

Yes, it can and the contents of do_install can be further pruned.

> >> +	echo "${KERNEL_VERSION}" > $kerneldir/kernel-abiversion
> >> +	
> >> +	# Copy files required for module builds
> >> +	cp System.map $kerneldir/System.map-${KERNEL_VERSION}
> >> +	cp Module.symvers $kerneldir/
> >> +	cp .config $kerneldir/
> >> +	mkdir -p $kerneldir/include/config
> >> +	cp include/config/kernel.release
> >>$kerneldir/include/config/kernel.release
> >> +
> >> +	# As of Linux kernel version 3.0.1, the clean target removes
> >> +	# arch/powerpc/lib/crtsavres.o which is present in
> >> +	# KBUILD_LDFLAGS_MODULE, making it required to build external modules.
> >> +	if [ ${ARCH} = "powerpc" ]; then
> >> +		mkdir -p $kerneldir/arch/powerpc/lib/
> >> +		cp arch/powerpc/lib/crtsavres.o
> >>$kerneldir/arch/powerpc/lib/crtsavres.o
> >> +	fi
> >> +
> >> +	mkdir -p $kerneldir/include/generated/
> >> +	cp -fR include/generated/* $kerneldir/include/generated/
> >> +
> >> +	if [ -d arch/${ARCH}/include/generated ]; then
> >> +		mkdir -p $kerneldir/arch/${ARCH}/include/generated/
> >> +		cp -fR arch/${ARCH}/include/generated/*
> >>$kerneldir/arch/${ARCH}/include/generated/
> >> +	fi
> 
> Some of the above is also present in do_install, do we need it in both
> places? If so, we should abstract it if possible to avoid duplication and
> risk of only one changing in the future when both should.

do_shared_workdir would be specifically to populate
STAGING_KERNEL_BUILDDIR. 

do_install would become "for target use only" in the form of packages.
We may well defer all of that to the kernel-devsrc recipe. The patch was
a proof of concept, not a complete implementation. If there is any
commonality left, we need to share a function, agreed.

> >> +}
> >> +
> >> +
> >>   python sysroot_stage_all () {
> >>       oe.path.copyhardlinktree(d.expand("${D}${KERNEL_SRC_PATH}"),
> >>d.expand("${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}"))
> >>   }
> >> diff --git a/meta/classes/module-base.bbclass
> >>b/meta/classes/module-base.bbclass
> >> index 9537ba9..c34eee7 100644
> >> --- a/meta/classes/module-base.bbclass
> >> +++ b/meta/classes/module-base.bbclass
> >> @@ -3,16 +3,18 @@ inherit kernel-arch
> >>   export OS = "${TARGET_OS}"
> >>   export CROSS_COMPILE = "${TARGET_PREFIX}"
> >>
> >> -export KERNEL_VERSION =
> >>"${@base_read_file('${STAGING_KERNEL_DIR}/kernel-abiversion')}"
> >> +export KERNEL_VERSION =
> >>"${@base_read_file('${STAGING_KERNEL_BUILDDIR}/kernel-abiversion')}"
> >>   KERNEL_OBJECT_SUFFIX = ".ko"
> >>
> >>   # kernel modules are generally machine specific
> >>   PACKAGE_ARCH = "${MACHINE_ARCH}"
> >>
> >> +do_configure[depends] += "virtual/kernel:do_install"
> 
> 
> I¹m not clear on the separation of do_shared_workdir and do_install now...

See above, this probably needs to change.

The patch was really a test to see how badly a build would explode with
separate source and builddir and whether the kernel build system can
cope with three separate locations (source, build objects, module). From
that perspective it passed in that I could build oprofile, perf and some
kernel modules. From here we need a step back and to go through and do
it "properly".

Cheers,

Richard



  reply	other threads:[~2015-01-07 21:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-07 12:26 RFC: Further kernel build process changes? Richard Purdie
2015-01-07 13:22 ` Bruce Ashfield
2015-01-07 18:33   ` Darren Hart
2015-01-07 21:16     ` Richard Purdie [this message]
2015-01-07 21:20       ` Bruce Ashfield
2015-01-13  1:19 ` Robert Yang
2015-01-13  1:27   ` Robert Yang
2015-01-13  2:59     ` Hart, Darren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1420665363.25779.73.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=dvhart@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox