[OE-core] RFC: Maintain backwards compatibility or not for module-base.bbclass

[Bruce Ashfield]

On Thu, Jan 16, 2014 at 8:58 AM, Peter Kjellerstedt
<peter.kjellerstedt at axis.com> wrote:
> Background: Back in September, Richard made a commit to
> linux-libc-headers.inc describing why one should not fork the
> linux-libc-headers recipe:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=babbf7a46acaefd9b36031483cafce053f607e66
>
> As a result I created a local bbclass for our layer called
> kernel-headers, which provides a recipe with kernel headers
> that match the actually used version of the Linux kernel.
> This was needed for packages that need to access hardware
> specific features that are not present in the generic kernel
> headers provided by linux-libc-headers.
>
> My intention for this class was that it should be generic
> enough to be able to upstream it to OE Core.
>
> Now, the other day a colleague of mine had a build failure due
> to this class. It turned out that even though the class adds a
> dependency on virtual/kernel and then uses the files that are
> installed to ${STAGING_KERNEL_DIR} when running oe_runmake
> headers_install, the command could fail because the
> ${STAGING_KERNEL_DIR}/scripts was not populated. After asking
> Richard about this, I learned that this is due to problems
> with the sstate cache and not knowing whether a 32 bit host or
> a 64 bit host was used to generate the files. Thus I also
> learned that the scripts are actually built as a result of
> building modules.
>
> Since I did not want my class to depend on modules having been
> built, I looked into modules.bbclass and modules-base.bbclass.
> There I found the function do_make_scripts() which is
> responsible for building  the kernel scripts. However, the
> current setup doesn't lend itself very well to use the
> modules-base.bbclass for something other than modules.
>
> My idea then was to break this part out into a separate class,
> kernel-scripts, which I did. You can find both the
> kernel-scripts and kernel-headers classes here:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=pkj/kernel-headers
>
> When I showed this to Richard he noted that my change was not
> backwards compatible (as I no longer provide the
> do_make_scripts() function from the module-base.bbclass).
> However, there is nothing besides module.bbclass in OE Core
> and meta-oe that use the module-base.bbclass.
>
> Anyway, I made a modified version that does maintain backwards
> compatibility for module-base.bbclass here:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=pkj/kernel-headers-backwards-compatible
>
> This time Richard complained about the extra class
> (kernel-scripts-base.bbclass), and noted that there was no
> way to win... He then suggested that I take the question of
> whether we need to maintain backwards compatibility for
> modules-base.bbclass to the mailing list.

FWIW: I agree that have to many small, single purpose
kernel-*.bbclasses is a pain,
since it provides granularity, but more opportunity for varying behaviour during
kernel builds.

I have uses of the module-base.bbclass and an expectation that it will generate
the scripts, largely around the SDK and some custom kernel recipes. So they
only inherit module.bbclass, and would be impacted if that functionality was
changed to require another inherit.

Speaking of that, we through something like this late last year with
automatically
restoring the scripts into the sysroot, which ended up being reverted:

see b2c948d56241ff7cdea2e9e68b740f305c72f5ca in oe-core

At least the module (and your scripts) class avoid the sstate problems and
compiler dependencies that we hit with that solution.

What are the alternatives to more classes, isn't this something that could be
a .inc routine ? And modules simply includes it, and you can do the same ..
but I suppose a .inc versus a class inherit is largely semantics in
the difference.

bottom line, my rambling says that backwards compatibility matters here, and
that if we can avoid a new class, that would also be a good thing.

Cheers,

Bruce

>
> So, here I am now. I do not know who else use the
> do_make_scripts() function from module-base.bbclass and in what
> way, and whether restructuring the functionality into the new
> kernel-scripts.bbclass without maintaining backwards
> compatibility would be a problem. If you know anything about
> this, please let me know.



>
> Any comments appreciated.
>
> //Peter
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"