All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu
Subject: Re: Next patches for the 2.6.25 queue
Date: Thu, 13 Dec 2007 13:32:02 -0800	[thread overview]
Message-ID: <20071213133202.11374f54.akpm@linux-foundation.org> (raw)
In-Reply-To: <20071213144642.GA7800@Krystal>

On Thu, 13 Dec 2007 09:46:42 -0500
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:

> Hi Andrew,
> 
> I would like to post my next patches in a way that would make it as
> easy for you and the community to review them. Currently, the patches
> that have really settled down are :
> 
> * For 2.6.25
> 
> - Text Edit Lock
>   - Looks-good-to Ingo Molnar.
> - Immediate Values
>   - Redux version, asked by Rusty
> 
> * For 2.6.25 ?
> 
> Another patchset that is technically ok (however Rusty dislikes the
> complexity inherent to the algorithms required to be reentrant wrt NMI
> and MCE, although it's been reviewed by the community for months). I
> have also replyed to Ingo's concerns about effeciency of my approach
> compared to dtrace by providing numbers, but he has not replyed yet.
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg238317.html
> 
> - Markers use Immediate Values
> 
> * Maybe for 2.6.26 ...
> 
> Once we have this, and the instrumentation (submitted as RFC in the past
> weeks), in the kernel, the only architecture dependent element that will
> be left is the LTTng timestamping code.
> 
> And then, from that point, the following patchset is mostly
> self-contained and stops modifying code all over the kernel tree. It
> is the LTTng tracer.
> 
> Trying to improve my approach : I guess that submitting at most 15
> patches at a time (each 1-2 days), against the -mmotm tree, would be the
> way to do it ?
> 

Just for some context, I have...

- 1,400-odd open bugzilla reports

- 719 emails saved away in my emailed-bug-reports folder, all of which
  need to be gone through, asking originators to retest and
  re-report-if-unfixed.

- A big ugly email titled "2.6.24-rc5-git1: Reported regressions from
  2.6.23" in my inbox.

All of which makes it a bit inappropriate to be thinking about
intrusive-looking new features.

Ho hum.  Just send me the whole lot against rc5-mm1 and I'll stick it in
there and we'll see what breaks.


  parent reply	other threads:[~2007-12-13 21:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-13 14:46 Next patches for the 2.6.25 queue Mathieu Desnoyers
2007-12-13 15:49 ` Adrian Bunk
2007-12-14 16:43   ` Mathieu Desnoyers
2007-12-15 22:14     ` Adrian Bunk
2007-12-13 21:32 ` Andrew Morton [this message]
2007-12-13 22:18   ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071213133202.11374f54.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.