acpi git versus x86_64 tree

acpi git versus x86_64 tree

[Andrew Morton]

I have problems here.  A large update has recently gone into the acpi devel
tree which trashes a lot of the acpi patches which I have thus far been
unable to get Len to pay attention to.  It also trashes a large number of
x86_64 patches which I have thus far been unable to get Andi to pay
attention to.

Having torn my hair out for a while I've decided to revert to yesterday's
version of the ACPI tree and I shall stop updating it.  This enables me to
at least maintain the x86_64 patches.

If/when Andi merges those x86_64 patches we have a huge conflict
outstanding between the acpi and x86_64 trees.  Whoever merges with Linus
second will lose, big-time.  Basically their work will need to be dropped
and redone.

The moral here is simple: x86_64 patches go through the x86_64 maintainer. 
Please do not attempt to maintain foreign patches in the acpi tree.


Oh, and I am getting *extremely* tired of sending patches to maintainers
over and over and over and over again, and receiving no response at all. 
And then eventually seeing them merge other patches which trash the patches
which I'm maintaining for them, and which they have previously ignored.

Re: acpi git versus x86_64 tree

[Len Brown]

> The moral here is simple: x86_64 patches go through the x86_64 maintainer.
> Please do not attempt to maintain foreign patches in the acpi tree.

Huh?  What x86_64 patches are in the acpi tree?

Re: acpi git versus x86_64 tree

[Andrew Morton]

On Thu, 14 Dec 2006 21:17:41 -0500
Len Brown <lenb@kernel.org> wrote:

> 
> > The moral here is simple: x86_64 patches go through the x86_64 maintainer.
> > Please do not attempt to maintain foreign patches in the acpi tree.
> 
> Huh?  What x86_64 patches are in the acpi tree?

I dunno.  This:

 arch/i386/kernel/acpi/boot.c                |  234 ++--
 arch/i386/kernel/acpi/earlyquirk.c          |   10 
 arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c |    1 
 arch/i386/kernel/cpu/cpufreq/longhaul.c     |   15 
 arch/i386/kernel/mpparse.c                  |    4 
 arch/i386/mach-es7000/es7000.h              |   25 
 arch/i386/mach-es7000/es7000plat.c          |   55 -
 arch/i386/pci/mmconfig.c                    |   26 
 arch/ia64/kernel/acpi.c                     |  186 ++--
 arch/x86_64/kernel/early-quirks.c           |    4 
 arch/x86_64/kernel/genapic.c                |    4 
 arch/x86_64/kernel/io_apic.c                |    6 
 arch/x86_64/kernel/mpparse.c                |   74 +
 arch/x86_64/kernel/setup.c                  |   65 +
 arch/x86_64/kernel/time.c                   |   52 -
 arch/x86_64/mm/srat.c                       |   48 -
 arch/x86_64/pci/mmconfig.c                  |   31 -

Re: acpi git versus x86_64 tree

[Len Brown]

On Thursday 14 December 2006 21:37, Andrew Morton wrote:
> On Thu, 14 Dec 2006 21:17:41 -0500
>
> Len Brown <lenb@kernel.org> wrote:
> > > The moral here is simple: x86_64 patches go through the x86_64
> > > maintainer. Please do not attempt to maintain foreign patches in the
> > > acpi tree.
> >
> > Huh?  What x86_64 patches are in the acpi tree?
>
> I dunno.  This:
>
>  arch/i386/kernel/acpi/boot.c                |  234 ++--
>  arch/i386/kernel/acpi/earlyquirk.c          |   10
>  arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c |    1
>  arch/i386/kernel/cpu/cpufreq/longhaul.c     |   15
>  arch/i386/kernel/mpparse.c                  |    4
>  arch/i386/mach-es7000/es7000.h              |   25
>  arch/i386/mach-es7000/es7000plat.c          |   55 -
>  arch/i386/pci/mmconfig.c                    |   26
>  arch/ia64/kernel/acpi.c                     |  186 ++--
>  arch/x86_64/kernel/early-quirks.c           |    4
>  arch/x86_64/kernel/genapic.c                |    4
>  arch/x86_64/kernel/io_apic.c                |    6
>  arch/x86_64/kernel/mpparse.c                |   74 +
>  arch/x86_64/kernel/setup.c                  |   65 +
>  arch/x86_64/kernel/time.c                   |   52 -
>  arch/x86_64/mm/srat.c                       |   48 -
>  arch/x86_64/pci/mmconfig.c                  |   31 -

These are ACPI patches, mostly due to a rather large ACPICA
update that brings the core up to date to 11/9 from 7/7.
The biggest part is the update to the table code to teach the
OS that it can simply map tables in place rather than copying them.
Nearly all of this series has been in -mm before.

I do regret that there are more variable re-names and whitespace
cleanups in this batch than I'd prefer -- seems there is never
a good time to do those...

-Len

Re: acpi git versus x86_64 tree

[Andrew Morton]

On Thu, 14 Dec 2006 21:54:41 -0500
Len Brown <lenb@kernel.org> wrote:

> On Thursday 14 December 2006 21:37, Andrew Morton wrote:
> > On Thu, 14 Dec 2006 21:17:41 -0500
> >
> > Len Brown <lenb@kernel.org> wrote:
> > > > The moral here is simple: x86_64 patches go through the x86_64
> > > > maintainer. Please do not attempt to maintain foreign patches in the
> > > > acpi tree.
> > >
> > > Huh?  What x86_64 patches are in the acpi tree?
> >
> > I dunno.  This:
> >
> >  arch/i386/kernel/acpi/boot.c                |  234 ++--
> >  arch/i386/kernel/acpi/earlyquirk.c          |   10
> >  arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c |    1
> >  arch/i386/kernel/cpu/cpufreq/longhaul.c     |   15
> >  arch/i386/kernel/mpparse.c                  |    4
> >  arch/i386/mach-es7000/es7000.h              |   25
> >  arch/i386/mach-es7000/es7000plat.c          |   55 -
> >  arch/i386/pci/mmconfig.c                    |   26
> >  arch/ia64/kernel/acpi.c                     |  186 ++--
> >  arch/x86_64/kernel/early-quirks.c           |    4
> >  arch/x86_64/kernel/genapic.c                |    4
> >  arch/x86_64/kernel/io_apic.c                |    6
> >  arch/x86_64/kernel/mpparse.c                |   74 +
> >  arch/x86_64/kernel/setup.c                  |   65 +
> >  arch/x86_64/kernel/time.c                   |   52 -
> >  arch/x86_64/mm/srat.c                       |   48 -
> >  arch/x86_64/pci/mmconfig.c                  |   31 -
> 
> These are ACPI patches, mostly due to a rather large ACPICA
> update that brings the core up to date to 11/9 from 7/7.
> The biggest part is the update to the table code to teach the
> OS that it can simply map tables in place rather than copying them.

When will it be sent to Linus?

I cannot feasibly carry this work, the outstanding x86_64 work, the
outstanding i386 work and the outstanding ACPI work in -mm.

As the acpi patch is the one which has disrupted the other trees I dropped
that, so what little bit of testing gets donw in -mm won't be available.

> Nearly all of this series has been in -mm before.
> 
> I do regret that there are more variable re-names and whitespace
> cleanups in this batch than I'd prefer -- seems there is never
> a good time to do those...

There are ways of doing these things which don't cause such breakage. 
Whitespace cleanups go to the subsystem maintainer and NOT in the ACPI
tree.  For renames, you can add back-compat defines in the acpi headers,
send that and the rename patch to the subsytem maintainer and when it's all
merged up, remove the back-compat stuff.  

Re: acpi git versus x86_64 tree

[Len Brown]

> When will it be sent to Linus?
>
> I cannot feasibly carry this work, the outstanding x86_64 work, the
> outstanding i386 work and the outstanding ACPI work in -mm.
>
> As the acpi patch is the one which has disrupted the other trees I dropped
> that, so what little bit of testing gets donw in -mm won't be available.

Until the ACPICA update can survive for a few rounds of -mm
with no regressions reported, I'm not going to send it to Linus.

So removing it from -mm in favor of Andi's patches that may
be up-stream bound shortly was the right decision.

> > Nearly all of this series has been in -mm before.
> > 
> > I do regret that there are more variable re-names and whitespace
> > cleanups in this batch than I'd prefer -- seems there is never
> > a good time to do those...
> 
> There are ways of doing these things which don't cause such breakage. 
> Whitespace cleanups go to the subsystem maintainer and NOT in the ACPI
> tree.  For renames, you can add back-compat defines in the acpi headers,
> send that and the rename patch to the subsytem maintainer and when it's all
> merged up, remove the back-compat stuff.  

Agreed.
Perhaps in January some re-write can be done to make the series smaller.

For now I will remove the ACPICA update from my test branch
so that it doesn't block the unrelated patches that should go up now.
The ACPICA update will still be available on a dedicated acpica branch.

thanks,
-Len

Re: acpi git versus x86_64 tree

[Andrew Morton]

On Fri, 15 Dec 2006 01:01:40 -0500
Len Brown <lenb@kernel.org> wrote:

> > When will it be sent to Linus?
> >
> > I cannot feasibly carry this work, the outstanding x86_64 work, the
> > outstanding i386 work and the outstanding ACPI work in -mm.
> >
> > As the acpi patch is the one which has disrupted the other trees I dropped
> > that, so what little bit of testing gets donw in -mm won't be available.
> 
> Until the ACPICA update can survive for a few rounds of -mm
> with no regressions reported, I'm not going to send it to Linus.
> 
> So removing it from -mm in favor of Andi's patches that may
> be up-stream bound shortly was the right decision.

I doubt if Andi is planning on getting much of this work into 2.6.20.

> > > Nearly all of this series has been in -mm before.
> > > 
> > > I do regret that there are more variable re-names and whitespace
> > > cleanups in this batch than I'd prefer -- seems there is never
> > > a good time to do those...
> > 
> > There are ways of doing these things which don't cause such breakage. 
> > Whitespace cleanups go to the subsystem maintainer and NOT in the ACPI
> > tree.  For renames, you can add back-compat defines in the acpi headers,
> > send that and the rename patch to the subsytem maintainer and when it's all
> > merged up, remove the back-compat stuff.  
> 
> Agreed.
> Perhaps in January some re-write can be done to make the series smaller.
> 
> For now I will remove the ACPICA update from my test branch
> so that it doesn't block the unrelated patches that should go up now.
> The ACPICA update will still be available on a dedicated acpica branch.

OK, thanks.  I'll resync with gti-acpi and will go through another round of
squirting patches at everyone.

But the problem remains: there is outstanding work in ACPICA which
conflicts with outstanding x86/x86_64 work.  Once those two patchsets
finally coincide somewhere, things will blow up.  

Re: acpi git versus x86_64 tree

[Len Brown]

> > For now I will remove the ACPICA update from my test branch
> > so that it doesn't block the unrelated patches that should go up now.
> > The ACPICA update will still be available on a dedicated acpica branch.
> 
> OK, thanks.  I'll resync with gti-acpi and will go through another round of
> squirting patches at everyone.

Andrew,
the acpi-test tree is ready for you to resume pulling it.

(for those of you who pull it and update the result: Sorry --
I created new history, as I dropped both the acpica and sysfs branches
from "test" -- the are available only on their dedicated branches.

At the moment, the only thing in acpi-test that I don't think is both
ready and appropriate for for 2.6.20-rc1 is the bay driver.

> But the problem remains: there is outstanding work in ACPICA which
> conflicts with outstanding x86/x86_64 work.  Once those two patchsets
> finally coincide somewhere, things will blow up.  

Alexey and I looked at this today and we think we can modify the ACPICA
update to touch fewer lines and cause fewer conflicts.

So the plan is to shrink the patch, merge it back into acpi-test,
let it stew in -mm, and then push to 2.6.21.

thanks,
-Len