[gentoo-user] Adding realtime-prempt kernel patches to gentoo-sources

[gentoo-user] Adding realtime-prempt kernel patches to gentoo-sources

[Mark Knecht]

Hi,
   I'm interested in using Ingo Molnar's realtime-preempt kernel
patches with a Gentoo kernel. I already use them with a Kernel.org
kernel but would prefer to one day see these be part of what Gentoo
supplies. This morning I did a --dry-run and see some messages like
this:

patching file Makefile
Hunk #1 FAILED at 1.
1 out of 2 hunks FAILED -- saving rejects to file Makefile.rej
patching file arch/arm/mach-pxa/corgi_ssp.c
patching file arch/i386/Kconfig
<SNIP>
patching file arch/mips/Kconfig
Hunk #3 succeeded at 907 (offset 2 lines).
Hunk #4 succeeded at 942 (offset 2 lines).
Hunk #5 succeeded at 1469 (offset 2 lines).
Hunk #6 succeeded at 1483 (offset 2 lines).
patching file arch/mips/kernel/Makefile
<SNIP>
patching file drivers/video/console/fbcon.c
Hunk #1 succeeded at 1063 (offset 11 lines).
Hunk #2 FAILED at 1091.
Hunk #3 succeeded at 2874 (offset 106 lines).
1 out of 3 hunks FAILED -- saving rejects to file
drivers/video/console/fbcon.c.rej
patching file drivers/video/console/vgacon.c


QUESTIONS:

1) Can I assume that whatever happened with the "Hunk #x succeeded"
that everything is OK? Maybe this was just a line number issue?

2) What can I do about the "Hunk #x FAILED" messages? 

No output files were created since it was only a dry run. I can run
again, get output files, and then look into it but I thought I'd ask
how folks go about this sort of thing before I pulled the trigger.

Thanks,
Mark

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Adding realtime-prempt kernel patches to gentoo-sources

[Christian Heim]

Mark Knecht wrote:
 > QUESTIONS:
> 
> 1) Can I assume that whatever happened with the "Hunk #x succeeded"
> that everything is OK? Maybe this was just a line number issue?
Yeah .. or and indent change or something similar.

> 
> 2) What can I do about the "Hunk #x FAILED" messages? 
Well to get that patch working, you *need* to take a look at the *.rej
files
which are created by patch -p1 < realtime-prempt.patch.

Most times this is only due to missing context. That means the line just
before
the one which should be added, is not there or another one is just in
the way.
So `patch` is unable to find the matching context.
> 
> No output files were created since it was only a dry run. I can run
> again, get output files, and then look into it but I thought I'd ask
> how folks go about this sort of thing before I pulled the trigger.

Regards Christian
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Adding realtime-prempt kernel patches to gentoo-sources

[Mark Knecht]

On 7/7/05, Christian Heim <christian.th.heim@gmx.de> wrote:
> Mark Knecht wrote:
>  > QUESTIONS:
> >
> > 1) Can I assume that whatever happened with the "Hunk #x succeeded"
> > that everything is OK? Maybe this was just a line number issue?
> Yeah .. or and indent change or something similar.
> 
> >
> > 2) What can I do about the "Hunk #x FAILED" messages?
> Well to get that patch working, you *need* to take a look at the *.rej
> files
> which are created by patch -p1 < realtime-prempt.patch.
> 
> Most times this is only due to missing context. That means the line just
> before
> the one which should be added, is not there or another one is just in
> the way.
> So `patch` is unable to find the matching context.
> >
> > No output files were created since it was only a dry run. I can run
> > again, get output files, and then look into it but I thought I'd ask
> > how folks go about this sort of thing before I pulled the trigger.
> 
> Regards Christian
> 

Hi Christian,
   Thanks for the response. There were just two problems, as best I
can tell. One was in the upper level makefile which the second was in
a more tecnical piece of code. I'm providing the output here more for
conversation and not really asking for technical help on changing
code. This is just for my learning.

   In the first one it appears that Gentoo does an extra version so I
can probably fake my way around this but changing the patch file
itself to expect the Gentoo kernel I want to patch. Is that a
reasonable strategy?

   In the second, since it's apparently just a difference in brakets
I'm more curious about why gentoo-sources would differ from what Ingo
was apparently expectinb in the kernel config file, but again it seems
pretty minor. Would you agree?

Thanks,
Mark

Makefile.rej:
***************
*** 1,7 ****
  VERSION = 2
  PATCHLEVEL = 6
  SUBLEVEL = 12
- EXTRAVERSION =
  NAME=Woozy Numbat

  # *DOCUMENTATION*
--- 1,7 ----
  VERSION = 2
  PATCHLEVEL = 6
  SUBLEVEL = 12
+ EXTRAVERSION = -RT-V0.7.51-11
  NAME=Woozy Numbat

  # *DOCUMENTATION*


drivers/video/console/fbcon.c.rej:

***************
*** 1092,1101 ****
        struct display *p = &fb_display[vc->vc_num];
        struct fbcon_ops *ops = info->fbcon_par;

-       if (!fbcon_is_inactive(vc, info))
                ops->putcs(vc, info, s, count, real_y(p, ypos), xpos,
                           get_color(vc, info, scr_readw(s), 1),
                           get_color(vc, info, scr_readw(s), 0));
  }

  static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
--- 1091,1101 ----
        struct display *p = &fb_display[vc->vc_num];
        struct fbcon_ops *ops = info->fbcon_par;

+       if (!fbcon_is_inactive(vc, info)) {
                ops->putcs(vc, info, s, count, real_y(p, ypos), xpos,
                           get_color(vc, info, scr_readw(s), 1),
                           get_color(vc, info, scr_readw(s), 0));
+       }
  }

  static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Adding realtime-prempt kernel patches to gentoo-sources

[Christian Heim]

Mark Knecht wrote:
> On 7/7/05, Christian Heim <christian.th.heim@gmx.de> wrote:
> 
> Hi Christian,
>    Thanks for the response. There were just two problems, as best I
> can tell. One was in the upper level makefile which the second was in
> a more tecnical piece of code. I'm providing the output here more for
> conversation and not really asking for technical help on changing
> code. This is just for my learning.
> 
>    In the first one it appears that Gentoo does an extra version so I
> can probably fake my way around this but changing the patch file
> itself to expect the Gentoo kernel I want to patch. Is that a
> reasonable strategy?

Make, if I understood you right, you would like to do the prempt stuff
ontop of gentoo-sources, right ?

Well then simply do the following:

# emerge a fresh copy of gentoo-sources
$ emerge gentoo-sources

# create a copy (or call it a fork ;)) of this kernel-directory
$ cd /usr/src
$ rsync -rt --progress linux-2.6.12-gentoo-r4/* linux-2.6.12-gentoo-r4.orig

# now go on and apply your patch to the
linux-2.6.12-gentoo-r4-directory. Once you are done, just go back to
/usr/src and create a diff between plain gentoo-sources and your
prempt-patched gentoo-sources.

$ cd /usr/src
$ diff -Nrup linux-2.6.12-gentoo-r4.orig linux-2.6.12-gentoo-r4 >
gentoo-sources-2.6.12-r4-prempt.patch

> In the first one it appears that Gentoo does an extra version so I
> can probably fake my way around this but changing the patch file
> itself to expect the Gentoo kernel I want to patch. Is that a
> reasonable strategy?

See above ;)

> In the second, since it's apparently just a difference in brakets
> I'm more curious about why gentoo-sources would differ from what Ingo
> was apparently expectinb in the kernel config file, but again it seems
> pretty minor. Would you agree?

Yeah, those rejects are really pretty minor. I guess these brakets
differences result from vesafb. But that's only a guess.

> Thanks,
> Mark
> 
> Makefile.rej:
> ***************
> *** 1,7 ****
>   VERSION = 2
>   PATCHLEVEL = 6
>   SUBLEVEL = 12
> - EXTRAVERSION =
>   NAME=Woozy Numbat
> 
>   # *DOCUMENTATION*
> --- 1,7 ----
>   VERSION = 2
>   PATCHLEVEL = 6
>   SUBLEVEL = 12
> + EXTRAVERSION = -RT-V0.7.51-11
>   NAME=Woozy Numbat
> 
>   # *DOCUMENTATION*
> 
> 
> drivers/video/console/fbcon.c.rej:
> 
> ***************
> *** 1092,1101 ****
>         struct display *p = &fb_display[vc->vc_num];
>         struct fbcon_ops *ops = info->fbcon_par;
> 
> -       if (!fbcon_is_inactive(vc, info))
>                 ops->putcs(vc, info, s, count, real_y(p, ypos), xpos,
>                            get_color(vc, info, scr_readw(s), 1),
>                            get_color(vc, info, scr_readw(s), 0));
>   }
> 
>   static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
> --- 1091,1101 ----
>         struct display *p = &fb_display[vc->vc_num];
>         struct fbcon_ops *ops = info->fbcon_par;
> 
> +       if (!fbcon_is_inactive(vc, info)) {
>                 ops->putcs(vc, info, s, count, real_y(p, ypos), xpos,
>                            get_color(vc, info, scr_readw(s), 1),
>                            get_color(vc, info, scr_readw(s), 0));
> +       }
>   }
> 
>   static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
> 

Regards Christian
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Adding realtime-prempt kernel patches to gentoo-sources

[Mark Knecht]

Christian,
   Again, thanks for the info. It's very helpful. I'll investigate
this more this evening.

cheers,
Mark

On 7/7/05, Christian Heim <christian.th.heim@gmx.de> wrote:
> Mark Knecht wrote:
> > On 7/7/05, Christian Heim <christian.th.heim@gmx.de> wrote:
> >
> > Hi Christian,
> >    Thanks for the response. There were just two problems, as best I
> > can tell. One was in the upper level makefile which the second was in
> > a more tecnical piece of code. I'm providing the output here more for
> > conversation and not really asking for technical help on changing
> > code. This is just for my learning.
> >
> >    In the first one it appears that Gentoo does an extra version so I
> > can probably fake my way around this but changing the patch file
> > itself to expect the Gentoo kernel I want to patch. Is that a
> > reasonable strategy?
> 
> Make, if I understood you right, you would like to do the prempt stuff
> ontop of gentoo-sources, right ?
> 
> Well then simply do the following:
> 
> # emerge a fresh copy of gentoo-sources
> $ emerge gentoo-sources
> 
> # create a copy (or call it a fork ;)) of this kernel-directory
> $ cd /usr/src
> $ rsync -rt --progress linux-2.6.12-gentoo-r4/* linux-2.6.12-gentoo-r4.orig
> 
> # now go on and apply your patch to the
> linux-2.6.12-gentoo-r4-directory. Once you are done, just go back to
> /usr/src and create a diff between plain gentoo-sources and your
> prempt-patched gentoo-sources.
> 
> $ cd /usr/src
> $ diff -Nrup linux-2.6.12-gentoo-r4.orig linux-2.6.12-gentoo-r4 >
> gentoo-sources-2.6.12-r4-prempt.patch
> 
> > In the first one it appears that Gentoo does an extra version so I
> > can probably fake my way around this but changing the patch file
> > itself to expect the Gentoo kernel I want to patch. Is that a
> > reasonable strategy?
> 
> See above ;)
> 
> > In the second, since it's apparently just a difference in brakets
> > I'm more curious about why gentoo-sources would differ from what Ingo
> > was apparently expectinb in the kernel config file, but again it seems
> > pretty minor. Would you agree?
> 
> Yeah, those rejects are really pretty minor. I guess these brakets
> differences result from vesafb. But that's only a guess.
> 
> > Thanks,
> > Mark
> >
> > Makefile.rej:
> > ***************
> > *** 1,7 ****
> >   VERSION = 2
> >   PATCHLEVEL = 6
> >   SUBLEVEL = 12
> > - EXTRAVERSION =
> >   NAME=Woozy Numbat
> >
> >   # *DOCUMENTATION*
> > --- 1,7 ----
> >   VERSION = 2
> >   PATCHLEVEL = 6
> >   SUBLEVEL = 12
> > + EXTRAVERSION = -RT-V0.7.51-11
> >   NAME=Woozy Numbat
> >
> >   # *DOCUMENTATION*
> >
> >
> > drivers/video/console/fbcon.c.rej:
> >
> > ***************
> > *** 1092,1101 ****
> >         struct display *p = &fb_display[vc->vc_num];
> >         struct fbcon_ops *ops = info->fbcon_par;
> >
> > -       if (!fbcon_is_inactive(vc, info))
> >                 ops->putcs(vc, info, s, count, real_y(p, ypos), xpos,
> >                            get_color(vc, info, scr_readw(s), 1),
> >                            get_color(vc, info, scr_readw(s), 0));
> >   }
> >
> >   static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
> > --- 1091,1101 ----
> >         struct display *p = &fb_display[vc->vc_num];
> >         struct fbcon_ops *ops = info->fbcon_par;
> >
> > +       if (!fbcon_is_inactive(vc, info)) {
> >                 ops->putcs(vc, info, s, count, real_y(p, ypos), xpos,
> >                            get_color(vc, info, scr_readw(s), 1),
> >                            get_color(vc, info, scr_readw(s), 0));
> > +       }
> >   }
> >
> >   static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
> >
> 
> Regards Christian
> --
> gentoo-user@gentoo.org mailing list
> 
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Adding realtime-prempt kernel patches to gentoo-sources

[Mark Knecht]

Hi,
   One more question if I might. What does this message mean? I'm
guessing that a patch in my patch file has already been applied in
gentoo-sources? If so then it would seem that I'd want to skip it. Is
that correct? Skipping the patch would seem reasonable if that's what
this means.

   Or am I misunderstanding this?

Thanks,
Mark

patching file include/asm-i386/string.h
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
9 out of 9 hunks ignored -- saving rejects to file include/asm-i386/string.h.rej

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Adding realtime-prempt kernel patches to gentoo-sources

[Christian Heim]

Mark Knecht wrote:
> Hi,
>    One more question if I might. What does this message mean? I'm
> guessing that a patch in my patch file has already been applied in
> gentoo-sources? If so then it would seem that I'd want to skip it. Is
> that correct? Skipping the patch would seem reasonable if that's what
> this means.
> 
>    Or am I misunderstanding this?
> 
> Thanks,
> Mark
> 
> patching file include/asm-i386/string.h
> Reversed (or previously applied) patch detected!  Assume -R? [n]
> Apply anyway? [n]
> Skipping patch.
> 9 out of 9 hunks ignored -- saving rejects to file include/asm-i386/string.h.rej

Yup, thats exactly the meaning of that message :)

Christian
-- 
gentoo-user@gentoo.org mailing list