From: Bas Mevissen <abuse@basmevissen.nl>
To: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: Openembedded Core <openembedded-core@lists.openembedded.org>
Subject: Re: Summary of kernel-devsrc package issues (Sumo)
Date: Mon, 04 Jun 2018 15:35:54 +0200 [thread overview]
Message-ID: <e1aa9b02f64579de35d33db98661d3c3@basmevissen.nl> (raw)
In-Reply-To: <CADkTA4NSLvgp8-YQom+5fcq-_ML_bPOFyCT39673ZKRdVFCHTA@mail.gmail.com>
On 2018-06-04 14:32, Bruce Ashfield wrote:
> On Mon, Jun 4, 2018 at 5:04 AM, Bas Mevissen <abuse@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 [1]
>> 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.
>
I wasn't aware of that. I looked up the one you posted in March and that
already addresses a lot of the issues I listed. Nice!
> So please, don't do any patches on top of the existing devsrc
> structure, since
> it is essentially obsolete.
>
Yes, definitely. I'm looking forward to see your updated version.
> Cheers,
>
> Bruce
>
>> Thanks,
>>
>> Bas.
>>
Cheers,
Bas.
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core [2]
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
>
> Links:
> ------
> [1] http://kernel-devsrc.bb
> [2] http://lists.openembedded.org/mailman/listinfo/openembedded-core
prev parent reply other threads:[~2018-06-04 13:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-04 9:04 Summary of kernel-devsrc package issues (Sumo) Bas Mevissen
2018-06-04 11:32 ` Alexander Kanavin
2018-06-04 13:23 ` Bas Mevissen
2018-06-04 12:32 ` Bruce Ashfield
2018-06-04 13:35 ` Bas Mevissen [this message]
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=e1aa9b02f64579de35d33db98661d3c3@basmevissen.nl \
--to=abuse@basmevissen.nl \
--cc=bruce.ashfield@gmail.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