fedora kernel utrace updates

[Roland McGrath]

I've started using quilt to maintain backport versions of my utrace patches.
http://people.redhat.com/roland/utrace/ now includes 2.6.21/ (for F-7) and
2.6.20.11 (for FC-6).  Done this way it is easy for me to plop in the new
utrace/ptrace code from the bleeding edge version when I have fixes, without
repeating the backport work, which is confined to the earlier patches in the
series.  

Since quilt doesn't have a handy feature for generating a single patch, and
I know better than to trust combinediff, I'd like to switch the Fedora
update kernels to using the broken out patches separately in the spec file.
If one were actually trying to keep track, this also makes it a little
easier to follow the changed patches in cvs, since there will be less
flutter around parts that aren't actually changing.

Any problem with that?  

Whoever is maintaining each update stream can tell me how they'd prefer to
handle updates.  You can snarf from my people page at will, or I can just
commit changed patches when I have a significant fix, or whatever.

For rawhide, it doesn't really matter to me one way or the other about using
the one patch or the series.  The "trunk" patchset is generated from GIT,
not quilt, and I already have scripts that generate the one patch we use
now.  If there is no reason not to, I'd probably switch it to using the
series just for consistency.

The F-7 spec change looks like this.  I renumbered some nearby patches to
give utrace the 10-30 range.  


Thanks,
Roland


Index: kernel-2.6.spec
===================================================================
RCS file: /cvs/pkgs/rpms/kernel/F-7/kernel-2.6.spec,v
retrieving revision 1.3226
diff -u -b -p -r1.3226 kernel-2.6.spec
--- kernel-2.6.spec	10 Jun 2007 01:28:50 -0000	1.3226
+++ kernel-2.6.spec	11 Jun 2007 20:40:07 -0000
@@ -397,20 +397,37 @@ Patch2: patch-2.6.21.5-rc2.bz2
 Patch3: stable-reverts.patch
 
 # Patches 10 through 99 are for things that are going upstream really soon.
-Patch10: linux-2.6-utrace.patch
-Patch11: nouveau-drm.patch
 
-Patch12: linux-2.6-fix-pmops-1.patch
-Patch13: linux-2.6-fix-pmops-2.patch
-Patch14: linux-2.6-fix-pmops-3.patch
-Patch15: linux-2.6-fix-pmops-4.patch
+Patch10: linux-2.6-sig_kernel-macros.patch
+Patch11: linux-2.6-recalc_sigpending_and_wake.patch
+Patch12: linux-2.6-utrace-tracehook.patch
+Patch13: linux-2.6-utrace-tracehook-ia64.patch
+Patch14: linux-2.6-utrace-tracehook-sparc64.patch
+Patch15: linux-2.6-utrace-tracehook-s390.patch
+Patch16: linux-2.6-utrace-tracehook-um.patch
+Patch17: linux-2.6-utrace-regset.patch
+Patch18: linux-2.6-utrace-regset-ia64.patch
+Patch19: linux-2.6-utrace-regset-sparc64.patch
+Patch20: linux-2.6-utrace-regset-s390.patch
+Patch21: linux-2.6-utrace-core.patch
+Patch22: linux-2.6-utrace-ptrace-compat.patch
+Patch23: linux-2.6-utrace-ptrace-compat-ia64.patch
+Patch24: linux-2.6-utrace-ptrace-compat-sparc64.patch
+Patch25: linux-2.6-utrace-ptrace-compat-s390.patch
+
+Patch30: nouveau-drm.patch
+
+Patch42: linux-2.6-fix-pmops-1.patch
+Patch43: linux-2.6-fix-pmops-2.patch
+Patch44: linux-2.6-fix-pmops-3.patch
+Patch45: linux-2.6-fix-pmops-4.patch
 
 # enable sysrq-c on all kernels, not only kexec
 # FIXME: upstream soon? When? It's been here for ages.
-Patch16: linux-2.6-sysrq-c.patch
+Patch46: linux-2.6-sysrq-c.patch
 
 # DRM bits for 965
-Patch17: linux-2.6-i965gm-support.patch
+Patch47: linux-2.6-i965gm-support.patch
 
 # Patches 100 through 500 are meant for architecture patches
 
@@ -1050,25 +1067,42 @@ cd linux-%{kversion}.%{_target_cpu}
 # Update to latest upstream.
 %patch1 -p1
 %patch2 -p1
-%patch3 -p1 -R
+%%patch3 -p1 -R
 
 # Patches 10 through 100 are meant for core subsystem upgrades
 
 # Roland's utrace ptrace replacement.
 %patch10 -p1
 %patch11 -p1
-
-# Power management fixes
 %patch12 -p1
 %patch13 -p1
 %patch14 -p1
 %patch15 -p1
+%patch16 -p1
+%patch17 -p1
+%patch18 -p1
+%patch19 -p1
+%patch20 -p1
+%patch21 -p1
+%patch22 -p1
+%patch23 -p1
+%patch24 -p1
+%patch25 -p1
+
+# nouveau-drm
+%patch30 -p1
+
+# Power management fixes
+%patch42 -p1
+%patch43 -p1
+%patch44 -p1
+%patch45 -p1
 
 # sysrq works always
-%patch16 -p1
+%patch46 -p1
 
 # DRM support for 965GM
-%patch17 -p1
+%patch47 -p1
 
 # Architecture patches

[Chuck Ebbert]

On 06/11/2007 04:46 PM, Roland McGrath wrote:
>  I've started using quilt to maintain backport versions of my
> utrace patches.
>  http://people.redhat.com/roland/utrace/ now includes 2.6.21/ (for F-7) and
>  2.6.20.11 (for FC-6).  Done this way it is easy for me to plop in the new
>  utrace/ptrace code from the bleeding edge version when I have fixes, without
>  repeating the backport work, which is confined to the earlier patches in the
>  series.  
>  
>  Since quilt doesn't have a handy feature for generating a single patch, and
>  I know better than to trust combinediff, I'd like to switch the Fedora
>  update kernels to using the broken out patches separately in the spec file.
>  If one were actually trying to keep track, this also makes it a little
>  easier to follow the changed patches in cvs, since there will be less
>  flutter around parts that aren't actually changing.
>   
'quilt snapshot' can be used to make combined patches, but I prefer
the separate patches anyway. For FC6 I'd prefer to do the commits;
if you'd notify us when you make a change that would help.

[Dave Jones]

On Mon, Jun 11, 2007 at 05:22:10PM -0400, Chuck Ebbert wrote:
>  On 06/11/2007 04:46 PM, Roland McGrath wrote:
>  > I've started using quilt to maintain backport versions of my utrace patches.
>  > http://people.redhat.com/roland/utrace/ now includes 2.6.21/ (for F-7) and
>  > 2.6.20.11 (for FC-6).  Done this way it is easy for me to plop in the new
>  > utrace/ptrace code from the bleeding edge version when I have fixes, without
>  > repeating the backport work, which is confined to the earlier patches in the
>  > series.  
>  > 
>  > Since quilt doesn't have a handy feature for generating a single patch, and
>  > I know better than to trust combinediff, I'd like to switch the Fedora
>  > update kernels to using the broken out patches separately in the spec file.
>  > If one were actually trying to keep track, this also makes it a little
>  > easier to follow the changed patches in cvs, since there will be less
>  > flutter around parts that aren't actually changing.
>  > 
>  
>  'quilt snapshot' can be used to make combined patches, but I prefer
>  the separate patches anyway. For FC6 I'd prefer to do the commits;
>  if you'd notify us when you make a change that would help. 
Same goes for F-7 I guess.  For devel however, it's a bit of a pain to
have to disable a dozen ApplyPatch's during the (brief) window
when I rebase, and you haven't rediffed utrace yet (if its trivial,
I've done it myself in the past, but it isn't always the case..)

In more recent times, I actually as part of my daily -git rebasing
have this tied into my scripts..
rm -f linux-2.6-utrace.patch
wget http://people.redhat.com/roland/utrace/2.6-current/linux-2.6-utrace.patch

So roll-up patches are still kinda handy for making that sort of
thing a breeze.

Better yet of course would be upstream integration, making this
whole problem go away.  But then, you knew that :)

	Dave

-- 
http://www.codemonkey.org.uk

[Dave Jones]

On Mon, Jun 11, 2007 at 01:46:44PM -0700, Roland McGrath wrote:
>  -%patch3 -p1 -R
>  +%%patch3 -p1 -R 
What happened there ?

	Dave

-- 
http://www.codemonkey.org.uk

[Roland McGrath]

>  On Mon, Jun 11, 2007 at 01:46:44PM -0700, Roland McGrath wrote:
>   > -%patch3 -p1 -R
>   > +%%patch3 -p1 -R
>  
>  What happened there ? 
Oops, sorry just a typo from a few days ago when I had to comment that out.

[Roland McGrath]

>  'quilt snapshot' can be used to make combined patches, but I
> prefer 
Ah, you mean "quilt pop -a && quilt snapshot && quilt push -a"
and then
"quilt diff --snapshot".  I hadn't noticed that.

>  the separate patches anyway. For FC6 I'd prefer to do the
> commits;
>  if you'd notify us when you make a change that would help. 
Right now the backport series have some fixes not in update kernels.  I
haven't done very exhaustive testing after the fresh backport work, so
there might be some regression there and I wouldn't push those before I get
some folks to do more testing.  If you aren't pushing an update real soon
anyway, now would be a good time to commit and do some unreleased builds I
can have people test.  

I am still working on some known bugs, and so there will be more updates
some time soon.  I'll let you know when all the pending issues are settled,
but if you do updates before then the current code is probably better than
status quo already.


Thanks,
Roland

[Roland McGrath]

>  Same goes for F-7 I guess.  For devel however, it's a bit of a
> pain to
>  have to disable a dozen ApplyPatch's during the (brief) window 
Really?  Inserting "true || {" before and "}" after seems not much
worse than 
commenting out a line or two.

>  when I rebase, and you haven't rediffed utrace yet (if its
> trivial,
>  I've done it myself in the past, but it isn't always the case..) 
Anyway, most of the time now I'm rebasing every day, lately more often than
rawhide.

>  In more recent times, I actually as part of my daily -git rebasing
>  have this tied into my scripts..
>  rm -f linux-2.6-utrace.patch
>  wget http://people.redhat.com/roland/utrace/2.6-current/linux-2.6-utrace.patch 
Both forms will continue to be available there, so whatever works for you.

>  Better yet of course would be upstream integration, making this
>  whole problem go away.  But then, you knew that :) 
Yes, well.  2.6.23 is sort of plausible I guess.


Thanks,
Roland

[Dave Jones]

On Mon, Jun 11, 2007 at 02:44:04PM -0700, Roland McGrath wrote:
>  > Same goes for F-7 I guess.  For devel however, it's a bit of
> a pain to
>  > have to disable a dozen ApplyPatch's during the (brief) window
>  
>  Really?  Inserting "true || {" before and "}" after seems not much
> worse than 
>  commenting out a line or two. 
yeah, could do it like that I suppose.

>  > In more recent times, I actually as part of my daily -git
> rebasing
>  > have this tied into my scripts..
>  > rm -f linux-2.6-utrace.patch
>  > wget http://people.redhat.com/roland/utrace/2.6-current/linux-2.6-utrace.patch
>  
>  Both forms will continue to be available there, so whatever works for you. 
cool.

>  > Better yet of course would be upstream integration, making this
>  > whole problem go away.  But then, you knew that :)
>  
>  Yes, well.  2.6.23 is sort of plausible I guess. 
That would tie in nicely for F8.

	Dave

-- 
http://www.codemonkey.org.uk

[Chuck Ebbert]

On 06/11/2007 05:40 PM, Roland McGrath wrote:

>  Right now the backport series have some fixes not in update kernels. 
> I
>  haven't done very exhaustive testing after the fresh backport work, so
>  there might be some regression there and I wouldn't push those before I get
>  some folks to do more testing.  If you aren't pushing an update real soon
>  anyway, now would be a good time to commit and do some unreleased builds I
>  can have people test.  
>   
In FC6 kernel 2959, building now. Please test soon, I do need to get a kernel
out but really want to get this update in. If it's broken I can revert.

[Roland McGrath]

>  In FC6 kernel 2959, building now. Please test soon, I do need to get
> a kernel
>  out but really want to get this update in. If it's broken I can revert. 
I haven't gotten folks to test that build yet, but already I have a few
more fixes (242694, 244162).  The updated patches are on the web (all versions).
Brew task 820195 is a scratch build of 1.2960.fc6 using a newer utrace patch.
Hopefully I'll get some testing done on that when it finishes.


Thanks,
Roland