linux-next: acpi/cpus4096 merge conflict

linux-next: acpi/cpus4096 merge conflict

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

Hi Len,

Today's linux-next merge of the acpi tree got a trivial conflict in
drivers/acpi/processor_throttling.c between commit
141ad0688adb53094d6f75b39b4b3b0625de0e07 ("acpi: use performance variant
for_each_cpu_mask_nr") from the cpus4096 tree and commit
08a4ab4a5fd58438840524ce22199c6bbd05816f ("ACPI: change processors from
array to per_cpu variable") from the acpi tree.

It is just a context conflict and I did the obvious fixup.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: acpi/cpus4096 merge conflict

[Len Brown]

On Thu, 12 Jun 2008, Stephen Rothwell wrote:

> Hi Len,
> 
> Today's linux-next merge of the acpi tree got a trivial conflict in
> drivers/acpi/processor_throttling.c between commit
> 141ad0688adb53094d6f75b39b4b3b0625de0e07 ("acpi: use performance variant
> for_each_cpu_mask_nr") from the cpus4096 tree and commit
> 08a4ab4a5fd58438840524ce22199c6bbd05816f ("ACPI: change processors from
> array to per_cpu variable") from the acpi tree.
> 
> It is just a context conflict and I did the obvious fixup.

thanks.

it would be ideal if the cpus4096 tree didn't scribble on drivers/acpi --
though I don't know if partitioning those patches is practical.

-Len

Re: linux-next: acpi/cpus4096 merge conflict

[Ingo Molnar]

* Len Brown <lenb@kernel.org> wrote:

> > Today's linux-next merge of the acpi tree got a trivial conflict in
> > drivers/acpi/processor_throttling.c between commit
> > 141ad0688adb53094d6f75b39b4b3b0625de0e07 ("acpi: use performance variant
> > for_each_cpu_mask_nr") from the cpus4096 tree and commit
> > 08a4ab4a5fd58438840524ce22199c6bbd05816f ("ACPI: change processors from
> > array to per_cpu variable") from the acpi tree.
> > 
> > It is just a context conflict and I did the obvious fixup.
> 
> thanks.
> 
> it would be ideal if the cpus4096 tree didn't scribble on drivers/acpi 
> -- though I don't know if partitioning those patches is practical.

well, it's a tree-wide API change and thus maintained in a separate 
tree.

	Ingo

Re: linux-next: acpi/cpus4096 merge conflict

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]

Hi Ingo,

On Thu, 12 Jun 2008 14:18:24 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> * Len Brown <lenb@kernel.org> wrote:
> 
> > > Today's linux-next merge of the acpi tree got a trivial conflict in
> > > drivers/acpi/processor_throttling.c between commit
> > > 141ad0688adb53094d6f75b39b4b3b0625de0e07 ("acpi: use performance variant
> > > for_each_cpu_mask_nr") from the cpus4096 tree and commit
> > > 08a4ab4a5fd58438840524ce22199c6bbd05816f ("ACPI: change processors from
> > > array to per_cpu variable") from the acpi tree.
> > > 
> > > It is just a context conflict and I did the obvious fixup.
> > 
> > thanks.
> > 
> > it would be ideal if the cpus4096 tree didn't scribble on drivers/acpi 
> > -- though I don't know if partitioning those patches is practical.
> 
> well, it's a tree-wide API change and thus maintained in a separate 
> tree.

Just a suggestion for next time (or this time if you don't mind a bit of
rearrangement):

Having now settled the interface changes down you could submit a patch to
Linus for his current tree that defines next_cpu_nr, cpus_weight_nr and
for_each_cpu_mask_nr to be next_cpu, cpus_weight and for_each_cpu_mask
respectively (just as they still will be for NR_CPUS <= 64).  Once that
has gone in (and I see no reason it wouldn't) you can send the patches
that only depend on those three interfaces existing to their respective
subsystem maintainers who will be now be able to apply them to their own
trees (maybe after merging in Linus' tree).

This way I don't have ongoing manual merges to do in the -next tree and
life is easier all round when we come to the next merge window at which
point the actual new implementations can go in.

This has been partially done (and more is being done) with dev_name() and
dev_set_name().

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: acpi/cpus4096 merge conflict

[Mike Travis]

Stephen Rothwell wrote:
> Hi Ingo,
> 
> On Thu, 12 Jun 2008 14:18:24 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>> * Len Brown <lenb@kernel.org> wrote:
>>
>>>> Today's linux-next merge of the acpi tree got a trivial conflict in
>>>> drivers/acpi/processor_throttling.c between commit
>>>> 141ad0688adb53094d6f75b39b4b3b0625de0e07 ("acpi: use performance variant
>>>> for_each_cpu_mask_nr") from the cpus4096 tree and commit
>>>> 08a4ab4a5fd58438840524ce22199c6bbd05816f ("ACPI: change processors from
>>>> array to per_cpu variable") from the acpi tree.
>>>>
>>>> It is just a context conflict and I did the obvious fixup.
>>> thanks.
>>>
>>> it would be ideal if the cpus4096 tree didn't scribble on drivers/acpi 
>>> -- though I don't know if partitioning those patches is practical.
>> well, it's a tree-wide API change and thus maintained in a separate 
>> tree.
> 
> Just a suggestion for next time (or this time if you don't mind a bit of
> rearrangement):
> 
> Having now settled the interface changes down you could submit a patch to
> Linus for his current tree that defines next_cpu_nr, cpus_weight_nr and
> for_each_cpu_mask_nr to be next_cpu, cpus_weight and for_each_cpu_mask
> respectively (just as they still will be for NR_CPUS <= 64).  Once that
> has gone in (and I see no reason it wouldn't) you can send the patches
> that only depend on those three interfaces existing to their respective
> subsystem maintainers who will be now be able to apply them to their own
> trees (maybe after merging in Linus' tree).
> 
> This way I don't have ongoing manual merges to do in the -next tree and
> life is easier all round when we come to the next merge window at which
> point the actual new implementations can go in.
> 
> This has been partially done (and more is being done) with dev_name() and
> dev_set_name().
> 

Sounds like a good idea ... I'll try to restructure future patches so the
common code can be pushed separately and has minimal effect on the base code.
Are there any git options to add a "dependency check" to insure that parent
patches are in place?

Thanks,
Mike

Re: linux-next: acpi/cpus4096 merge conflict

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

Hi Mike,

On Thu, 12 Jun 2008 11:31:16 -0700 Mike Travis <travis@sgi.com> wrote:
> 
> Sounds like a good idea ... I'll try to restructure future patches so the
> common code can be pushed separately and has minimal effect on the base code.
> Are there any git options to add a "dependency check" to insure that parent
> patches are in place?

None that I know of.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]