[ltt-dev] patches for 31-rc5?

[ltt-dev] patches for 31-rc5?

[Gregory Haskins]

Are there any in the works?  If not, perhaps I can take a stab at the
forward port.

-Greg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20090812/e6f407bc/attachment-0003.pgp>

[ltt-dev] patches for 31-rc5?

[Gregory Haskins]

Are there any in the works?  If not, perhaps I can take a stab at the
forward port.

-Greg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20090812/e6f407bc/attachment-0002.pgp>

[ltt-dev] patches for 31-rc5?

[Gregory Haskins]

Are there any in the works?  If not, perhaps I can take a stab at the
forward port.

-Greg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20090812/e6f407bc/attachment-0001.pgp>

[ltt-dev] patches for 31-rc5?

[Mathieu Desnoyers]

* 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.

Mathieu

> -Greg
> 



> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev


-- 
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/20090813/5b0d8bb2/attachment-0003.pgp>

[ltt-dev] patches for 31-rc5?

[Mathieu Desnoyers]

* 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.

Mathieu

> -Greg
> 



> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev


-- 
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/20090813/5b0d8bb2/attachment-0002.pgp>

[ltt-dev] patches for 31-rc5?

[Mathieu Desnoyers]

* 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.

Mathieu

> -Greg
> 



> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev


-- 
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/ltt-dev/attachments/20090813/5b0d8bb2/attachment.pgp>

[ltt-dev] patches for 31-rc5?

[Mathieu Desnoyers]

* 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.

Note that the cpufreq stuff and the alternative cleanup at the beginning
of the patchset are already merged in mainline.

I will not have the necessary time to do the port for a while, it will
probably have to wait closer to 2.6.31 on my side. But patches are
welcome.

Thanks,

Mathieu

> Mathieu
> 
> > -Greg
> > 
> 
> 
> 
> > _______________________________________________
> > ltt-dev mailing list
> > ltt-dev at lists.casi.polymtl.ca
> > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68



> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev


-- 
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/20090813/0bef5ae1/attachment-0003.pgp>

[ltt-dev] patches for 31-rc5?

[Mathieu Desnoyers]

* 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.

Note that the cpufreq stuff and the alternative cleanup at the beginning
of the patchset are already merged in mainline.

I will not have the necessary time to do the port for a while, it will
probably have to wait closer to 2.6.31 on my side. But patches are
welcome.

Thanks,

Mathieu

> Mathieu
> 
> > -Greg
> > 
> 
> 
> 
> > _______________________________________________
> > ltt-dev mailing list
> > ltt-dev at lists.casi.polymtl.ca
> > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68



> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev


-- 
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/20090813/0bef5ae1/attachment-0002.pgp>

[ltt-dev] patches for 31-rc5?

[Mathieu Desnoyers]

* 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.

Note that the cpufreq stuff and the alternative cleanup at the beginning
of the patchset are already merged in mainline.

I will not have the necessary time to do the port for a while, it will
probably have to wait closer to 2.6.31 on my side. But patches are
welcome.

Thanks,

Mathieu

> Mathieu
> 
> > -Greg
> > 
> 
> 
> 
> > _______________________________________________
> > ltt-dev mailing list
> > ltt-dev at lists.casi.polymtl.ca
> > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68



> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev


-- 
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/ltt-dev/attachments/20090813/0bef5ae1/attachment.pgp>

[ltt-dev] patches for 31-rc5?

[Gregory Haskins]

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.
> 
> Note that the cpufreq stuff and the alternative cleanup at the beginning
> of the patchset are already merged in mainline.
> 
> I will not have the necessary time to do the port for a while, it will
> probably have to wait closer to 2.6.31 on my side. But patches are
> welcome.

Ok, Thanks for the reply Mathieu.  If I get a chance (largely driven by
how bad I need the tracer in 31 at any given moment ;) I will take a
crack at it.

Regards,
-Greg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20090813/12c6fa45/attachment.pgp>

[ltt-dev] patches for 31-rc5?

[Gregory Haskins]

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.
> 
> Note that the cpufreq stuff and the alternative cleanup at the beginning
> of the patchset are already merged in mainline.
> 
> I will not have the necessary time to do the port for a while, it will
> probably have to wait closer to 2.6.31 on my side. But patches are
> welcome.

Ok, Thanks for the reply Mathieu.  If I get a chance (largely driven by
how bad I need the tracer in 31 at any given moment ;) I will take a
crack at it.

Regards,
-Greg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20090813/12c6fa45/attachment-0003.pgp>

[ltt-dev] patches for 31-rc5?

[Gregory Haskins]

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.
> 
> Note that the cpufreq stuff and the alternative cleanup at the beginning
> of the patchset are already merged in mainline.
> 
> I will not have the necessary time to do the port for a while, it will
> probably have to wait closer to 2.6.31 on my side. But patches are
> welcome.

Ok, Thanks for the reply Mathieu.  If I get a chance (largely driven by
how bad I need the tracer in 31 at any given moment ;) I will take a
crack at it.

Regards,
-Greg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20090813/12c6fa45/attachment-0002.pgp>

[ltt-dev] patches for 31-rc5?

[Gregory Haskins]

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?

Kind Regards,
-Greg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20090820/07c6596e/attachment.pgp>

[ltt-dev] patches for 31-rc5?

[Gregory Haskins]

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?

Kind Regards,
-Greg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20090820/07c6596e/attachment-0003.pgp>

[ltt-dev] patches for 31-rc5?

[Gregory Haskins]

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?

Kind Regards,
-Greg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20090820/07c6596e/attachment-0002.pgp>

[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-0002.pgp>

[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/ltt-dev/attachments/20090820/574bc4a9/attachment.pgp>

[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>