Patchwork Proposed update for https://wiki.ubuntu.com/Kernel/KernelBisection inquiry

login
register
mail settings
Submitter Christopher M. Penalver
Date Dec. 23, 2013, 5:37 p.m.
Message ID <CAF4BKcB4t_YLXM39kcKBfQubSWtuhCs07Ty1Fbd++FqJ0+KG1w@mail.gmail.com>
Download mbox | patch
Permalink /patch/304823/
State New
Headers show

Comments

Christopher M. Penalver - Dec. 23, 2013, 5:37 p.m.
Hello everyone. I wanted to e-mail you to get your feedback on a
proposed draft for updating the end of the KernelBisection article
(which has been remarkably successful in enabling new and experienced
bisectors to bisect their own kernel regressions).

The high level for this proposed draft is that a common event for bug
reporters is they want to test a patch not available in an upstream
tree (ex. linux-stable). However, they tend to get quite confused on
what to do step-by-step (as I was when I was Googling it all out). I
didn't find any article with a comprehensive click-for-click example,
I had to pick out what I needed from a number of articles, and dig
through a ton that were largely useless or didn't apply.

Hence, while the proposed draft would fit the logical flow of the
article placed at the end, as when one has finished commit bisecting
and an upstream patch was submitted but not merged, it may be better
placed in a different article, but I haven't really found one at this
point.

What do you think?

-START-
= Testing a patch from upstream =

Lets assume you may have identified an upstream patch that hasn't been
commited to an upstream branch, and you would like to test it out. Let
us take as an example the following upstream patch:

testfix.patch
http://www.spinics.net/lists/linux-acpi/msg47755.html

Start copying from the line where it notes:

save this file to your Desktop as testfix.patch. Then execute at a terminal:
git config --global user.email "you@example.com" && git config
--global user.name "Your Name" && git clone
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
~/Desktop/linux-stable && patch
~/Desktop/linux-stable/drivers/acpi/video.c ~/Desktop/testfix.patch &&
git add . && git commit

Now in the new window type: {{{
example }}}

press Ctrl+O -> Enter -> Ctrl+X. Then, type at a terminal:
git log -n 1 | grep commit

which should post the commit:
commit <COMMIT>

Use this commit in the below terminal command:
git checkout <COMMIT> && cp /boot/config-`uname -r` .config && yes ''
| make oldconfig && make-kpkg clean && CONCURRENCY_LEVEL=`getconf
_NPROCESSORS_ONLN` fakeroot make-kpkg --initrd
--append-to-version=-custom2 kernel_image kernel_headers && cd .. &&
sudo dpkg -i *.deb

If for whatever reason the new kernel doesn't boot, it may not be you
did something wrong, but just that it won't boot with this commit
applied.
-END-

Christopher M. Penalver
E-Mail: christopher.m.penalver@gmail.com
Andy Whitcroft - Dec. 23, 2013, 6:58 p.m.
On Mon, Dec 23, 2013 at 11:37:55AM -0600, Christopher M. Penalver wrote:
> Hello everyone. I wanted to e-mail you to get your feedback on a
> proposed draft for updating the end of the KernelBisection article
> (which has been remarkably successful in enabling new and experienced
> bisectors to bisect their own kernel regressions).
> 
> The high level for this proposed draft is that a common event for bug
> reporters is they want to test a patch not available in an upstream
> tree (ex. linux-stable). However, they tend to get quite confused on
> what to do step-by-step (as I was when I was Googling it all out). I
> didn't find any article with a comprehensive click-for-click example,
> I had to pick out what I needed from a number of articles, and dig
> through a ton that were largely useless or didn't apply.
> 
> Hence, while the proposed draft would fit the logical flow of the
> article placed at the end, as when one has finished commit bisecting
> and an upstream patch was submitted but not merged, it may be better
> placed in a different article, but I haven't really found one at this
> point.
> 
> What do you think?
> 
> -START-
> = Testing a patch from upstream =
> 
> Lets assume you may have identified an upstream patch that hasn't been
> commited to an upstream branch, and you would like to test it out. Let
> us take as an example the following upstream patch:
> 
> testfix.patch
> http://www.spinics.net/lists/linux-acpi/msg47755.html
> 
> Start copying from the line where it notes:
> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> 
> to the last code line before the double dash:
>  static int register_count;
> 
> Your patch file should exactly as shown, honoring all spaces, or lack thereof:

You shuldn't need to rip the above and below bits as git should understand
it in full (as patch has always done too).  Indeed if it has a 'diff
--git' header then it is in git email format.  Saving the email as a
file and applying it with 'git am <filename>' will apply it including
the right ownership.

> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> index 995e91b..b3032f8 100644
> --- a/drivers/acpi/video.c
> +++ b/drivers/acpi/video.c
> @@ -85,7 +85,7 @@ module_param(allow_duplicates, bool, 0644);
>   * For Windows 8 systems: if set ture and the GPU driver has
>   * registered a backlight interface, skip registering ACPI video's.
>   */
> -static bool use_native_backlight = false;
> +static bool use_native_backlight = true;
>  module_param(use_native_backlight, bool, 0644);
> 
>  static int register_count;
> 
> save this file to your Desktop as testfix.patch. Then execute at a terminal:
> git config --global user.email "you@example.com" && git config
> --global user.name "Your Name" && git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> ~/Desktop/linux-stable && patch
> ~/Desktop/linux-stable/drivers/acpi/video.c ~/Desktop/testfix.patch &&
> git add . && git commit
> 
> Now in the new window type: {{{
> example }}}
> 
> press Ctrl+O -> Enter -> Ctrl+X. Then, type at a terminal:
> git log -n 1 | grep commit
> 
> which should post the commit:
> commit <COMMIT>
> 
> Use this commit in the below terminal command:
> git checkout <COMMIT> && cp /boot/config-`uname -r` .config && yes ''

If you just committed the patch it would be the currnet commit, so there
would be no reason to check it out again.

> | make oldconfig && make-kpkg clean && CONCURRENCY_LEVEL=`getconf
> _NPROCESSORS_ONLN` fakeroot make-kpkg --initrd
> --append-to-version=-custom2 kernel_image kernel_headers && cd .. &&
> sudo dpkg -i *.deb
> 
> If for whatever reason the new kernel doesn't boot, it may not be you
> did something wrong, but just that it won't boot with this commit
> applied.

-apw
Christopher M. Penalver - Dec. 24, 2013, 4:36 p.m.
Andy, thank you for your quick response.

>> -START-
>> = Testing a patch from upstream =
>>
>> Lets assume you may have identified an upstream patch that hasn't been
>> commited to an upstream branch, and you would like to test it out. Let
>> us take as an example the following upstream patch:
>>
>> testfix.patch
>> http://www.spinics.net/lists/linux-acpi/msg47755.html
>>
>> Start copying from the line where it notes:
>> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
>>
>> to the last code line before the double dash:
>>  static int register_count;
>>
>> Your patch file should exactly as shown, honoring all spaces, or lack thereof:
>
> You shuldn't need to rip the above and below bits as git should understand
> it in full (as patch has always done too).  Indeed if it has a 'diff
> --git' header then it is in git email format.  Saving the email as a
> file and applying it with 'git am <filename>' will apply it including
> the right ownership.

Given the situation of a new bisector (I'll lump myself in this as
well), how would one looking at the mailing list post through a web
browser (where domains are hidden by the archive system) save the
e-mail as a file as you are suggesting? For example:
Copy from what points?
Save as what file extension specifically?

As wel, I'm not sure what the gain would be given all one would want
to do is quickly test the patch, and then discard the commit
immediately afterwards. It could be mentioned as a suggestion at the
end to reset their tree back to the defaults via:
git fetch origin;git fetch origin master;git reset --hard FETCH_HEAD

>> save this file to your Desktop as testfix.patch. Then execute at a terminal:
>> git config --global user.email "you@example.com" && git config
>> --global user.name "Your Name" && git clone
>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>> ~/Desktop/linux-stable && patch
>> ~/Desktop/linux-stable/drivers/acpi/video.c ~/Desktop/testfix.patch &&
>> git add . && git commit

I made a slight error here. It should be:
git config --global user.email "you@example.com" && git config
--global user.name "Your Name" && git clone
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
~/Desktop/linux-stable && patch
~/Desktop/linux-stable/drivers/acpi/video.c ~/Desktop/testfix.patch &&
cd ~/Desktop/linux-stable && git add . && git commit

>>
>> which should post the commit:
>> commit <COMMIT>
>>
>> Use this commit in the below terminal command:
>> git checkout <COMMIT> && cp /boot/config-`uname -r` .config && yes ''
>
> If you just committed the patch it would be the currnet commit, so there
> would be no reason to check it out again.

Good point!

Christopher M. Penalver
E-Mail: christopher.m.penalver@gmail.com

Patch

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c

to the last code line before the double dash:
 static int register_count;

Your patch file should exactly as shown, honoring all spaces, or lack thereof:
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 995e91b..b3032f8 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -85,7 +85,7 @@  module_param(allow_duplicates, bool, 0644);
  * For Windows 8 systems: if set ture and the GPU driver has
  * registered a backlight interface, skip registering ACPI video's.
  */
-static bool use_native_backlight = false;
+static bool use_native_backlight = true;
 module_param(use_native_backlight, bool, 0644);

 static int register_count;