From: Darren Hart <dvhart@linux.intel.com>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: Patch for fixing build issues with external kernel modules.
Date: Mon, 09 May 2011 13:53:19 -0700 [thread overview]
Message-ID: <4DC8543F.3090501@linux.intel.com> (raw)
In-Reply-To: <201105092038.15641.leitl@fim.uni-passau.de>
On 05/09/2011 11:38 AM, Franz Leitl wrote:
> Am Montag 09 Mai 2011, 20:23:19 schrieb Darren Hart:
>> On 05/09/2011 10:53 AM, Koen Kooi wrote:
>>> Op 9 mei 2011, om 19:32 heeft Franz Leitl het volgende geschreven:
>>>> Hi,
>>>>
>>>> Am Montag 09 Mai 2011, 18:28:06 schrieben Sie:
>>>>>> I've tried to get compcache kernel module building against 2.6.34 from
>>>>>> shr- core but found some issues with kernel.bbclass and
>>>>>> module.bbclass.
>>>>>>
>>>>>> The kernel.bbclass deletes the .c files from scripts directory which
>>>>>> are later needed by make prepare to recreate bound.h and other files.
>>>>>> Compcache kernel module, for example, depends on bounds.h.
>>>>>
>>>>> The bounds.h should not need to be recreated. It is created during the
>>>>> build of the kernel, and since 2.6.26, the makefile knows not to remove
>>>>> it.
>>>>
>>>> Compache does not build without bounds.h and this file is missing in the
>>>> staging directory for what ever reason.
>>>
>>> I ran into the same and I did the following:
>>>
>>> http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstrumen
>>> ts/commit/?id=7bcba149f05cc9c5d8ce956ee40e2c6849601470
>>
>> Thanks Koen, I knew we had discussed this once before. In your case,
>> IIRC, you found that the "make clean" deleted bounds.h, even with the
>> fix from 2.6.26 applied.
>>
>> At the time we agreed that patching the kernel bbclasses for a bug in a
>> particular kernel version wasn't a good plan. I'm concerned that Franz
>> is hitting this with 2.6.34.
>>
>> Franz, can you confirm that bounds.h exists before the clean and does
>> not exist after the clean? Some simple instrumentation to kernel.bbclass
>> should be able to do this.
> I'll try to find out.
>
>> If so, we need to look into why that is happening. Simply not deleting
>> the C files from the source isn't an acceptable fix to save 1 file.
> The c files are deleted by the kernel.bbclass not by "make clean" while make
> clean deletes the bounds.h... Who is doing the wrong thing now? kernel.bbclass
> removing the bounds.c, kernel's make clean removing the bounds.h or the module
> author relying on modules.h?
The kernel should not remove bounds.h, that is documented in the
Makefile. If it does, it's a bug.
>
> I don't know if/what the problem is with regenerating some things in
> module.bbclass. It is already done with "make scripts". Cleaning up
> things to save diskspace and recreating if needed does not seem to
> bad to me. Am I missing something?
The scripts are regenerated as they are host specific. If you were to
use an sstate package, you don't want host-specific binaries in it. (We
aren't there yet, but we want to keep that in mind).
It's just about fixing it properly instead of applying a band-aid.
Regenerating something that shouldn't have been deleted in the first
place is a band-aid, and you can go that route in your own recipe if you
like (per Koen's patch), but that doesn't belong in the core kernel classes.
Thanks,
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
next prev parent reply other threads:[~2011-05-09 20:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-08 22:16 Patch for fixing build issues with external kernel modules Franz Leitl
2011-05-08 22:30 ` Franz Leitl
2011-05-09 16:28 ` Darren Hart
2011-05-09 17:32 ` Franz Leitl
2011-05-09 17:53 ` Koen Kooi
2011-05-09 18:23 ` Darren Hart
2011-05-09 18:38 ` Franz Leitl
2011-05-09 20:53 ` Darren Hart [this message]
2011-05-10 1:40 ` Franz Leitl
2011-05-10 1:56 ` Franz Leitl
2011-05-10 20:23 ` Darren Hart
2011-05-10 22:50 ` Franz Leitl
2011-05-23 23:37 ` Darren Hart
2011-05-24 0:19 ` Darren Hart
2011-05-09 18:20 ` Darren Hart
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=4DC8543F.3090501@linux.intel.com \
--to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.