Re: linux-next: manual merge of the perfmon3 tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ingo,

On Tue, 25 Nov 2008 17:51:18 +0100 Ingo Molnar <mingo@xxxxxxx> wrote:
>
> There are a number of ways to do that - and we'll sure be able to work 
> that out - but first please submit the full patchset (x86 and generic 
> bits as well) to lkml with the x86 maintainers Cc:-ed.

Let see ... the permfmon patches have been submitted to LKML several
times over the past couple of years.  In their latest incarnation they
were posted to LKML on October 18 (lkml is, of course, also the mailing
list for x86 patches noted in MAINTAINERS - maybe you should submit a
patch noting that x86 code has to be submitted on x86@xxxxxxxxxx as
well).  There has been ample time for the x86 maintainers to comment and
notice that their code is being modified.  I have seen no attempt at
review from them.

Also this code has been in linux-next since next-20081106 (i.e. November
6) and the only problem reports have been from the ia64 people.

> In any case, until that happens and until there's agreement with the 
> x86 maintainers (there's none at the moment) the perfmon3 tree (or at 
> least its x86 bits) needs to be removed from linux-next. I already see 
> a number of problems with the patchset that we'll have to work out via 
> an iterative review process.

That process has been happening except it seems that the x86 maintainers
haven't bothered to participate.  If, as you say, all the x86 parts have
to go via the x86 tree, then be aware that this woukd probably delay x86
perfmon integration until 2.6.30 or later (*cough* ftrace *cough*).  As
Andrew pointed out in another thread you seem to have missed, the
integration of perfmon (or something like it) is way over due.  The way
he suggested to go forward was to get it into linux-next and aim for
2.6.29 integration.

Several other architectures want this code in the kernel, so if they have
to wait for the x86 maintainers to decide what they want, then the only
way forward may be to separate the generic parts of the code and get that
integrated along with one of the other architectures.

/me dons flame-proof suite :-)
-- 
Cheers,
Stephen Rothwell                    sfr@xxxxxxxxxxxxxxxx
http://www.canb.auug.org.au/~sfr/

Attachment: pgpgJDzG8KFCU.pgp
Description: PGP signature


[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux