Openembedded Core Discussions
 help / color / mirror / Atom feed
* Summary of kernel-devsrc package issues (Sumo)
@ 2018-06-04  9:04 Bas Mevissen
  2018-06-04 11:32 ` Alexander Kanavin
  2018-06-04 12:32 ` Bruce Ashfield
  0 siblings, 2 replies; 5+ messages in thread
From: Bas Mevissen @ 2018-06-04  9:04 UTC (permalink / raw)
  To: Openembedded Core



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.

Thanks,

Bas.




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Summary of kernel-devsrc package issues (Sumo)
  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
  1 sibling, 1 reply; 5+ messages in thread
From: Alexander Kanavin @ 2018-06-04 11:32 UTC (permalink / raw)
  To: Bas Mevissen, Openembedded Core

On 06/04/2018 12:04 PM, Bas Mevissen wrote:
> 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.

This is probably better discussed here:
https://lists.yoctoproject.org/listinfo/linux-yocto

Alex



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Summary of kernel-devsrc package issues (Sumo)
  2018-06-04  9:04 Summary of kernel-devsrc package issues (Sumo) Bas Mevissen
  2018-06-04 11:32 ` Alexander Kanavin
@ 2018-06-04 12:32 ` Bruce Ashfield
  2018-06-04 13:35   ` Bas Mevissen
  1 sibling, 1 reply; 5+ messages in thread
From: Bruce Ashfield @ 2018-06-04 12:32 UTC (permalink / raw)
  To: Bas Mevissen; +Cc: Openembedded Core

[-- Attachment #1: Type: text/plain, Size: 3810 bytes --]

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 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@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"

[-- Attachment #2: Type: text/html, Size: 4885 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Summary of kernel-devsrc package issues (Sumo)
  2018-06-04 11:32 ` Alexander Kanavin
@ 2018-06-04 13:23   ` Bas Mevissen
  0 siblings, 0 replies; 5+ messages in thread
From: Bas Mevissen @ 2018-06-04 13:23 UTC (permalink / raw)
  To: Alexander Kanavin; +Cc: Openembedded Core

On 2018-06-04 13:32, Alexander Kanavin wrote:
> On 06/04/2018 12:04 PM, Bas Mevissen wrote:
>> 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.
> 
> This is probably better discussed here:
> https://lists.yoctoproject.org/listinfo/linux-yocto
> 

Tnx for the pointer. However, this surprises me a bit. The charter of 
that ML says: "Development list for the linux-yocto*.git Linux kernel 
repositories.", while my issues are with a package contained in 
openembedded-core.


> Alex

Regards,

Bas.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Summary of kernel-devsrc package issues (Sumo)
  2018-06-04 12:32 ` Bruce Ashfield
@ 2018-06-04 13:35   ` Bas Mevissen
  0 siblings, 0 replies; 5+ messages in thread
From: Bas Mevissen @ 2018-06-04 13:35 UTC (permalink / raw)
  To: Bruce Ashfield; +Cc: Openembedded Core

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2018-06-04 13:35 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox