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@×××.de> wrote:
> Mark Knecht wrote:
> > On 7/7/05, Christian Heim <christian.th.heim@×××.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@g.o mailing list
>
>

-- 
gentoo-user@g.o mailing list