[ltt-dev] patches for 31-rc5?

[Mathieu Desnoyers]

* Gregory Haskins (gregory.haskins at gmail.com) wrote:
> Hi Mathieu
> 
> Mathieu Desnoyers wrote:
> > * Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
> >> * Gregory Haskins (gregory.haskins at gmail.com) wrote:
> >>> Are there any in the works?  If not, perhaps I can take a stab at the
> >>> forward port.
> >>>
> >> Not yet, but -rc5 sounds like a good timing to start forward porting.
> >> I'll look into this today.
> >>
> > 
> > Hrm, the instrumentation part will take a while to port, because we have
> > more and more clashes with ftrace.
> > 
> > If you want to start working on this, please provide patches in the
> > form:
> > 
> > original-patch.reject-fix-2.6.31.patch
> > 
> > for each patch which has rejects, so I can look at the result and merge
> > them through the patchset.
> 
> I thought I would try to automate this process a little bit, so I wrote
> a script to run through and stop when it hits rejects, create the new
> patch, etc.
> 
> I figured I should check to see if it is generating output like you
> expect, before I do all the work.
> 
> What it does is refresh each patch with the non-conflicts, and then
> generates a new patch with the same as the original, but with ".fixes"
> appended to the end, and a "Fixes for 2.6.31-rc6" prologue.
> 
> (And yes, I know the "From:" attribution of the original patches is
> wrong since it is assigning credit to me..I tried to fix this but it
> didn't work...just ignore the "From" field in the original patch for now)
> 
> Here is a trial run of the first few patches.  When the original and
> fixes patch is empty, I means "drop the patch" since its already upstream.
> 
> ftp://ftp.novell.com/dev/ghaskins/patch-2.6.31-rc6-0.155.tar.bz2
> 
> Does this look about right?
> 

Good enough. Although cpufreq-add-gov-mutex.patch should be removed
because the problem has been fixed differently by upstream.

The beginning of my 2.6.31-rc5 series file attempt looked like:

#kernel trace thread flag : required for arch-dependent syscall entry/exit
#instrumentation.
#posted.
#merged.cpufreq-remove-rwsem-lock-from-CPUFREQ_GOV_STOP-call.patch
#merged.cpufreq-fix-timer-teardown-in-conservative-governor.patch
#merged.cpufreq-fix-timer-teardown-in-ondemand-governor.patch
#merged.cpufreq-remove-rwsem-lock-from-CPUFREQ_GOV_STOP-call-missing-modification.patch
#merged.cpufreq-cleanup-cpufreq_add_dev.patch
#merged.cpufreq-fix-compile-failure-in-cpufreq-c.patch
#merged.cpufreq-add-gov-mutex.patch
#merged.cpufreq-ondemand-and-conservative-remove-dbs-mutex.patch

#merged.x86-cleanup-alternative.h.patch
x86-amd-fix-cmpxchg-read-acquire-barrier.patch
#merged.documentation-sample-tracepoints-code-fix.patch

Then the kernel trace thread flags are cumbersome because we have to
merge with ftrace modifications by adding our own flags. s390 probably
has the most important change, where the way they've done it with ftrace
is brilliant and better than how I've done it in LTTng.

Mathieu


> Kind Regards,
> -Greg
> 



-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20090820/574bc4a9/attachment-0003.pgp>