All of lore.kernel.org
 help / color / mirror / Atom feed
From: autif khan <autif.mlist@gmail.com>
To: Bruce Ashfield <bruce.ashfield@windriver.com>
Cc: yocto@yoctoproject.org, Darren Hart <dvhart@linux.intel.com>
Subject: Re: How do I patch the kernel before it is built?
Date: Mon, 6 Feb 2012 17:10:14 -0500	[thread overview]
Message-ID: <CADzUK1Lv4Ke9GN=R5Tjm0SVQcxpiHg3-ZwKDpNXYtFEcdH5mPQ@mail.gmail.com> (raw)
In-Reply-To: <4F304D1C.6090802@windriver.com>

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

\>>>>>>>>> I could not find a way to patch the kernel source before its is
>>>>>>>>> built.
>>>>>>>>>
>>>>>>>>> I promise to update the Yocto wiki's How do I section when I have a
>>>>>>>>> working solution for the following :-)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This should be covered in the existing documentation and also the
>>>>>>>> more general bitbake/oe-core docs.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Here is what I am trying to do:
>>>>>>>>>
>>>>>>>>> 1) Patch the kernel (add VID/PID to hid_ignore_list in
>>>>>>>>> drivers/hid/hid-core.c and also to add the VID/PID to .h file)
>>>>>>>>> 2) Build the kernel - no change here - standard kernel build
>>>>>>>>> 3) Build a kernel module
>>>>>>>>>
>>>>>>>>> I have a meta layer where I am keeping my changes. I am guessing
>>>>>>>>> that
>>>>>>>>> I need to:
>>>>>>>>>
>>>>>>>>> a) write a bbappend file to accomplish #1
>>>>>>>>> b) write a recipe to accomplish #3
>>>>>>>>>
>>>>>>>>> I have written recipes before, but just for libraries and autotools
>>>>>>>>> based applications. Not for a kernel module. If there is a recipe
>>>>>>>>> out
>>>>>>>>> there for some other module, I would be happy to steal from it.
>>>>>>>>>
>>>>>>>>> Please advise how I can go about patching the kernel and if there
>>>>>>>>> is
>>>>>>>>> a
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> It's just like any other package. If your changes are simple, then
>>>>>>>> generating patches and putting them on the SRC_URI via a bbappend in
>>>>>>>> your layer is all you need. If you have complex changes, there are
>>>>>>>> options
>>>>>>>> to manage them via git or via feature descriptions.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I tried this - attached at the end of this email are my bbappend file
>>>>>> and my patches, when the recipe is bitbaked, it does not actually
>>>>>> apply the patch.
>>>>>>
>>>>>> On a similar note - there seems to be a file in
>>>>>> meta/recipes-kernel/linux/linux-yocto called
>>>>>> tools-perf-no-scripting.patch
>>>>>>
>>>>>> However, it does not seem to be used anywhere - is this just crud or I
>>>>>> am missing something? I was hoping to cheat off of the recipe that
>>>>>> uses it.
>>>>>>
>>>>>>>>> recipe for a kernel module - please point me to it.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Darren validated and updated the kernel module example, so he'd
>>>>>>>> probably
>>>>>>>> got this closer at hand than I do.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> See the hello-mod example under meta/recipes-kernel/hello-mod
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thank you for this recipe - it seems like this is exactly what I was
>>>>>> looking for. I will cheat off of this as soon as I can patch my
>>>>>> kernel.
>>>>>>
>>>>>>
>>>>>> R E C I P E
>>>>>>
>>>>>> autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$ cat
>>>>>> linux-yocto_3.0.bbappend
>>>>>> FILESEXTRAPATHS_prepend := "${THISDIR}:"
>>>>>> SRC_URI += " file://linux/drivers/hid/hid-core.c.diff \
>>>>>>             file://linux/drivers/hid/hid-ids.h.diff "
>>>>>> PR = "r3"
>>>>>> autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$
>>>>>>
>>>>>> P A T C H
>>>>>>
>>>>>>
>>>>>>
>>>>>> autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux/drivers/hid$
>>>>>
>>>>>
>>>>>
>>>>> Taking a look at this (while I was cutting and pasting), this should
>>>>> be in in the
>>>>> a 'linux-yocto' subdirectory if you want bitbake to pickup the patch
>>>>> and
>>>>> make it
>>>>> available to the linux-yocto recipe.
>>>>>
>>>>> i.e.
>>>>>
>>>>> ~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux-yocto/drivers/hid
>>>>>
>>>>> And don't use 'linux-yocto' in your file:// reference on the SRC_URI,
>>>>> that part is
>>>>> automatic.
>>>>
>>>>
>>>>
>>>> I tried this just now - here is what happens:
>>>>
>>>> Case - patch is in linux/linux-yocto/drivers/hid, SRC_URI ref is
>>>> file://drivers/hid/file.diff
>>>> Result: Fetcher failure for URL: 'file://drivers/hid/hid-core.c.diff
>>>
>>>
>>>
>>> If you get a fetcher failire, you have it in the wrong place.
>>>
>>> Note: this has nothing to do with the kernel and is a general
>>> bitbake/oe-core question.
>>>
>>>
>>>>
>>>> Case - patch is in linux/linux-yocto/drivers/hid, SRC_URI ref is
>>>> file://linux-yocto/drivers/hid/file.diff
>>>
>>>
>>>
>>> Interesting. I've never had to specify linux-yocto in my SRC_URIs,
>>> so something strange it going on here.
>>>
>>> Does anyone else have ideas here ?
>>>
>>>
>>>
>>>> Result - my diff files are copied in a directory called linux-yocto in
>>>>
>>>>
>>>> tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3
>>>>
>>>> These patches are not applied in
>>>>
>>>>
>>>> tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3/linux
>>>>
>>>> Here is what the work directory looks like
>>>>
>>>>
>>>>
>>>> autif@fpbm:~/ssd/minimal/tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3$
>>>> ls
>>>> git  license-destdir  linux  linux-crownbay-standard-build  linux-yocto
>>>>  temp
>>>>
>>>>
>>>> autif@fpbm:~/ssd/minimal/tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3$
>>>>
>>>>
>>>> I have attached the original set of files as a tar gzip.
>>>
>>>
>>>
>>> I'll take them for a spin.
>>>
>>>
>>>>
>>>>> (and yes, I see 'edison' was the branch now)
>>>>
>>>>
>>>>
>>>> Yes, I am using Yocto 1.0 - very soon I will migrate to M2 - pending
>>>> tasks at hand :-)
>>>
>>>
>>>
>>> I'll have to dig up a 1.0 tree, since I don't have anything of that
>>> vintage available to me.
>>>
>>> But I know that patched worked then, and am absolutely sure that it
>>> works in 1.1 and master.
>>
>>
>> OK, I switched to M2 release and now, I have a different error:
>>
>> Case - diff files are in recipes/linux/linux-yocto, SRC_URI is
>> file://drivers/hid/hid-core.c.diff
>> Result - ERROR: Function 'Fetcher failure for URL:
>> 'file://drivers/hid/hid-core.c.diff'. Unable to fetch URL
>> file://drivers/hid/hid-core.c.diff from any source.' failed
>>
>>
>> Did, I misunderstood you when you said that I should rename the files
>> dir to linux-yocto - the name of the recipe and remove it from the
>> SRC_URI?
>
>
> Every build that I do with my meta-kernel-dev has some out of tree
> patches. It's a form of continual regression testing that I do out
> of habit.
>
> My bbappend looks like this:
>
> SRC_URI =
> "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta
> \
>           file://make.patch \
>           file://subdir/make2.patch \
>           file://subdir/make3.patch"
>
>
>> pwd
> /home/bruce/yocto/poky-extras/meta-kernel-dev/recipes-kernel/linux
>> tree linux-yocto
> linux-yocto
> ├── make.patch
> └── subdir
>    ├── make2.patch
>    └── make3.patch
>
> These are always applied to my build.
>
> Cheers,
>
> Bruce
>

I will try that next. However, it seems like something is wrong with
my setup may be.

I was reading the log.do_patch file and it seems like bitbake is
mixing my build and recipes directory.

The recipe and logs are attached in this email. Once again, I have
switched to M2 now. This is no longer with Yocto 1.0.

[-- Attachment #2: cant_patch_kernel.tar.gz --]
[-- Type: application/x-gzip, Size: 6763 bytes --]

  reply	other threads:[~2012-02-06 22:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-31 16:45 How do I patch the kernel before it is built? autif khan
2012-01-31 16:51 ` Joshua Lock
2012-01-31 16:51 ` Bruce Ashfield
2012-01-31 16:54   ` Darren Hart
2012-02-06 19:35     ` autif khan
2012-02-06 19:39       ` Bruce Ashfield
2012-02-06 19:46       ` Bruce Ashfield
2012-02-06 20:18         ` autif khan
2012-02-06 20:24           ` Bruce Ashfield
2012-02-06 21:43             ` autif khan
2012-02-06 21:58               ` Bruce Ashfield
2012-02-06 22:10                 ` autif khan [this message]
2012-02-07  1:20                   ` Bruce Ashfield
2012-02-07  1:28                     ` Bruce Ashfield
2012-02-07 19:01                       ` autif khan
2012-02-08 15:31     ` autif khan
2012-02-09 14:39       ` 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='CADzUK1Lv4Ke9GN=R5Tjm0SVQcxpiHg3-ZwKDpNXYtFEcdH5mPQ@mail.gmail.com' \
    --to=autif.mlist@gmail.com \
    --cc=bruce.ashfield@windriver.com \
    --cc=dvhart@linux.intel.com \
    --cc=yocto@yoctoproject.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.