[OE-core] Summary of kernel-devsrc package issues (Sumo)

[Bruce Ashfield]

On Mon, Jun 4, 2018 at 5:04 AM, Bas Mevissen <abuse at basmevissen.nl> wrote:

>
>
> Hi all,
>
> I ran into several issues with kernel-devsrc when building Poky Sumu with
> the meta-freescale layer for an Freescale i.mx6sx ARM board. In this
> mail(thread) I would like to collect them all and discuss the possible
> options to resolve them.
>
> * Install dependency issues (both during image creation and manual install
> on the board):
>
> The kernel-devsrc spec file defines a number of auto-generated run-time
> dependencies. These include
> (1) /bin/awk
> (2) /usr/bin/python
>
> (1) is due to scripts/ver_linux being an awk script using /bin/awk in its
> shebang in various (vendor) kernels, even recent ones. Instead of fixing
> all those kernel sources, I would suggest:
> 1a) adding a link to /bin/awk in the awk or the kernel-devsrc package
> 1b) automatically fix the kernel source included in the kernel-devsrc
> package
> 1c) having a more helpful error message?
>
> (2) is normally fine, but on my build, there is only /usr/bin/python3. A
> manually created symlink fixed the issue. I'm wondering what a more
> permanent solution would be:
> 2a) Fix all Python script in the installed kernel source like 1b)? (the
> python3-native package does create such a symlink, but not the target one!)
> 2b) See whether there is a package that already creates that symlink and
> make kernel-devsrc depend on it?
>
> * External module build issue:
>
> When building an external module (rtl8812au driver) on the board using
> kernel-devsrc, I ran into the following issues:
>
> (3) No symlink from /lib/modules/`uname -r`/build to the kernel source.
> Solution:
> 3a) Add this symlink (and optionally "source") to kernel-devsrc,
> comparable to Fedora kernel-headers package
>
> (4) The scripts where not build, resulting in build error. Solution:
> 4b) Pre-build scripts ("make scripts") in kernel-devsrc. Should be ok, as
> the package is already arch dependent.
>
> (remarkably, there is mention of both in the kernel-devsrc.bb file, but I
> think the current solutions are wrong as the package is not ready-to-use
> currently)
>
> * Multiple kernel support:
>
> When developing, multiple kernel versions might be installed. Current
> version of the package installs in /usr/src/kernel without the kver in the
> patch.
>
> (5) So you can have only 1 set of kernel sources installed. Proposal:
> (5a) Install in /usr/src/kernels/`uname r` following the way Fedora does
> it.
>
> * Huge size of package
>
> (6) The package contains an awful lot of files and is huge. Not all of
> them are needed to compile external kernel modules
> 6a) Remove the sources and only provide what is needed to build external
> kernel modules (like fedora)
> 6b) Create the package suggested at 6a) (or add it to kernel-dev) and keep
> the devsrc as the full-source alternative.
>
>
> Your thoughts? I'm more than happy to fix the issues and provide patches.
> However, I need input on what direction to go on the issues I ran into
> until now.
>

There's already a completely re-written kernel-devsrc that I posted in the
last
dev cycle, which will be re-sent in the next few days. The only reason it
didn't
merge was due to a multlib issue, which should be sorted out now.

So please, don't do any patches on top of the existing devsrc structure,
since
it is essentially obsolete.

Cheers,

Bruce


>
> Thanks,
>
> Bas.
>
>
> --
> _______________________________________________
> 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180604/c761d95c/attachment-0002.html>