All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Cc: yocto@yoctoproject.org
Subject: Re: modify a kernel patch
Date: Wed, 9 May 2012 10:40:14 -0400	[thread overview]
Message-ID: <4FAA81CE.3050601@windriver.com> (raw)
In-Reply-To: <CACW_hTZ=VNBcsX+LjcVpk+pOL9UhFqE1fzBiPg3uG+J_wsHg+A@mail.gmail.com>

On 12-05-09 10:27 AM, Frans Meulenbroeks wrote:
> 2012/5/9 Bruce Ashfield<bruce.ashfield@windriver.com>:
>> On 12-05-09 10:11 AM, Frans Meulenbroeks wrote:
>>>
>
>>>
>>>
>>> Bruce, thanks a lot for your help! Greatly appreciated!
>>>
>>> I've verified this at work and noticed that things are not exactly
>>> working as expected (although I was able to create a decent patch).
>>> The max7311.patch I have sent to you also creates a few new files.
>>> Apparently after a quilt refresh of my patch these new files do not
>>> appear in the patch any more (but files that are modified are
>>> updated). Guess this is because the new files are unknown to git.
>>
>>
>> Yes, that's a property of guilt. I used to carry a patch to git to
>> actually fix that behaviour, but I was since educated on the subtleties
>> about why it's better to have new files explicitly added by the
>> user before git (and hence guilt) will pick them up.
>>
>>
>>>
>>> It might be that it is better to add new files in a separate patch (or
>>> maybe even with something like file://xx.c)
>>> Not sure though as I am not an expert in this area.
>>
>>
>> When working with any rejected patch under git/guilt/git-am, I am now
>> in the habit of checking git status, git adding the files I want, and
>> then issuing the tag and guilt refresh. Scripts are great for this
>> as well.
>>
>> That's my suggestion on how to deal with new files.
>>
>> Cheers,
>>
>> Bruce
>>
>
> Seems like a decent flow to me.
> Actually I probably rework my patch to indeed add the new files
> separately as files.
>
> The good news is that after this exercise my kernel with most of the
> patches added builds and works!
> Only issue left seems to be 3 new locally added drivers that refer to
> of_register_platform_driver and of_unregister_platform_driver
> This used to be there in 2.6.38 but has been removed in (iirc) 2.6.39.
> Guess I can/have to sort this out....

If you can't get it working, give a shout, there's a few ppc guys around
that we can ping :)

>
> Best regards, Frans.
>
> PS: probably we should in the wiki or manual or so have some howto's
> to describe common tasks like the above one (the making of the kernel
> patch that is).

Definitely. I've got a set of things I'll be documenting for the 1.3
release as part of the stabilization, fit and finish theme. This is
one of them.

This was a good reminder of the gap :)

Cheers,

Bruce






      reply	other threads:[~2012-05-09 14:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-07 14:41 modify a kernel patch Frans Meulenbroeks
2012-05-07 14:48 ` Bruce Ashfield
2012-05-07 19:29   ` Frans Meulenbroeks
2012-05-07 19:36     ` Bruce Ashfield
2012-05-08  7:18       ` Frans Meulenbroeks
2012-05-08 12:42         ` Bruce Ashfield
2012-05-08 13:03           ` Frans Meulenbroeks
2012-05-08 13:22             ` Bruce Ashfield
2012-05-08 19:20             ` Bruce Ashfield
2012-05-08 22:40               ` Autif Khan
2012-05-09  1:12                 ` Bruce Ashfield
2012-05-09  4:31                   ` Khem Raj
2012-05-09 14:11               ` Frans Meulenbroeks
2012-05-09 14:14                 ` Bruce Ashfield
2012-05-09 14:27                   ` Frans Meulenbroeks
2012-05-09 14:40                     ` Bruce Ashfield [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=4FAA81CE.3050601@windriver.com \
    --to=bruce.ashfield@windriver.com \
    --cc=fransmeulenbroeks@gmail.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.