Xen devel - Mar 2012 - [GIT PULL] (xen) stable/for-linus-3.4-tag-two (or three depending on your taste) for v3.4-rc0

Hey Linus,

I mentioned in the first git pull I would be sending another one after the cpu
frequency
tree was pulled and here it is:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
stable/for-linus-3.4-tag-two

However, I might have messed up a bit. The reason for this delay was that one
patch
("xen/cpufreq: Disable the cpu frequency scaling drivers from
loading") in my tree depended on
("provide disable_cpufreq() function to disable the API.") which was
in the cpufreq tree.
To not cause bisection issues (such as hitting on my patch without the
dependency patch and
getting a compile failure), I cherry-picked that specific patch into my branch
from the cpufreq
tree - and is part of the above mentioned tag.

So the problem is when I do the git pull against your latest, it
doesn''t apply  the "provide .."
but I still see it in the git shortlog!? Is that OK?

If that is not OK, I''ve done the unthinkable and created another branch
(and yet another tag),
which is based on your yesterday tree and is based off
cf821923ba9aa0917165a12573bdd6dc0a354421.
With that the shortlog does not include the "provide.." patch
(obviously since that is the
merge of the cpufreq tree).

So if you prefer to pull that one instead, please pull:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
stable/for-linus-3.4-tag-three

Either way, the git diff looks exactly the same.

Igor Mammedov (1):
      xen: initialize platform-pci even if xen_emul_unplug=never

Jan Beulich (1):
      xen/tmem: cleanup

Konrad Rzeszutek Wilk (6):
      provide disable_cpufreq() function to disable the API.
      xen/cpufreq: Disable the cpu frequency scaling drivers from loading.
      xen/acpi-processor: Do not depend on CPU frequency scaling drivers.
      xen/acpi: Remove the WARN''s as they just create noise.
      xen/smp: Fix bringup bug in AP code.
      xen/acpi: Fix Kconfig dependency on CPU_FREQ

Stefano Stabellini (1):
      xen: support pirq_eoi_map

 arch/x86/xen/setup.c             |    2 ++
 arch/x86/xen/smp.c               |    6 ++++++
 drivers/block/xen-blkfront.c     |    3 +++
 drivers/net/xen-netfront.c       |    4 ++++
 drivers/xen/Kconfig              |    5 ++---
 drivers/xen/events.c             |   26 +++++++++++++++++++++++---
 drivers/xen/platform-pci.c       |    5 -----
 drivers/xen/tmem.c               |   21 ++++++++-------------
 drivers/xen/xen-acpi-processor.c |    4 ++--
 include/xen/interface/physdev.h  |   21 +++++++++++++++++++++
 include/xen/tmem.h               |    6 +++++-
 11 files changed, 76 insertions(+), 27 deletions(-)

On Sat, Mar 24, 2012 at 6:56 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>
> So the problem is when I do the git pull against your latest, it
doesn''t apply  the "provide .."
> but I still see it in the git shortlog!? Is that OK?
The fact that you see it in the shortlog just means that the commit is
there. If you don''t see it in the diff, it is because somebody else
applied the *same* patch, but as a separate commit, so the merge will
have just considered it a no-op.

It''s not uncommon, and if it happens occasionally with duplicated
patches that''s fine. If it happens a *lot* that two people keep
applying the same patch to their different branches, that implies that
there''s some workflow problem where people continually keep on
stepping on each others toes, and that''s a problem.

But the occasional "oops, that change was already in mainline" is
fine.

                         Linus