From mboxrd@z Thu Jan 1 00:00:00 1970 From: compudj@krystal.dyndns.org (Mathieu Desnoyers) Date: Thu, 20 Aug 2009 11:20:13 -0400 Subject: [ltt-dev] patches for 31-rc5? In-Reply-To: <4A8D66DD.2050502@gmail.com> References: <4A82DDAA.1060801@gmail.com> <20090813135241.GB31960@Krystal> <20090813142324.GA32765@Krystal> <4A8D66DD.2050502@gmail.com> Message-ID: <20090820152013.GA10556@Krystal> Message-ID: <20090820152013.4HuAYP4IUgrNVYVD7c9RncU0dtpzjWgmvK4tlulFczc@z> * 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: