On Thu, May 28, 2015 at 12:52 AM, Dan Williams <dan.j.williams(a)intel.com> wrote:
On Wed, May 27, 2015 at 3:36 PM, Rafael J. Wysocki
> On Thu, May 28, 2015 at 12:24 AM, Dan Williams <dan.j.williams(a)intel.com>
>> Jens, please pull from...
>> ...to receive the libnd sub-system for the next merge window. This has
>> been through 3 rounds of review. Incremental diffstats and links to
>> previous postings:
>> v1: 39 files changed, 13102 insertions(+), 36 deletions(-)
>> v2: 30 files changed, 3166 insertions(+), 3935 deletions(-)
>> v3: 33 files changed, 2202 insertions(+), 1233 deletions(-)
>> v4: Full diffstat since v3
>> Documentation/blockdev/libnd.txt | 2 +-
>> arch/x86/Kconfig | 4 ++
>> arch/x86/kernel/pmem.c | 92 +++++++++++++++++++++++------------
>> drivers/acpi/nfit.c | 20 ++++----
>> drivers/acpi/nfit.h | 4 +-
>> drivers/block/Kconfig | 8 ---
>> drivers/block/Makefile | 1 -
>> drivers/block/e820_pmem.c | 100
>> drivers/block/nd/Kconfig | 10 ++++
>> drivers/block/nd/btt.h | 2 +-
>> drivers/block/nd/namespace_devs.c | 5 +-
>> drivers/block/nd/pmem.c | 2 +-
>> drivers/block/nd/test/nfit.c | 10 ++--
>> include/acpi/acuuid.h | 16 +++---
>> 14 files changed, 105 insertions(+), 171 deletions(-)
>> delete mode 100644 drivers/block/e820_pmem.c
>> 1/ Kill drivers/block/e820_pmem.c, we can just register pmem
>> regions directly from arch/x86/kernel/pmem.c without need for an
>> intermediary driver (Christoph).
>> 2/ Update to latest NFIT UUID definitions (Toshi). This
>> merges cleanly with, and is identical to the include/acpi/
>> NFIT enabling in Rafael's linux-pm.git/bleeding-edge branch.
> Well, I didn't expect you to send a pull request for this right away
> to be honest.
No worries, we can address these concerns now...
> Can you please pull from my acpica branch and rebase your patches on
> top of that by any chance?
I noticed that bleeding-edge rebased from the last time I checked is
that branch stable enough to use as a baseline?
There is a separate acpica branch (called "acpica") that's not going
to be rebased. Please use that one.
> And no, the "merges cleanly" part isn't sufficient
as it'll create a
> mess of a history if merged together like that. Can we do that
> properly instead?
If I merge 'bleeding-edge' on top of v4.1-rc5 followed by this branch
and do a "git log include/acpi/acuuid.h" then the full history from
the 'bleeding-edge' branch shows up.
I'm fine with doing the rebase, but I don't quite see the mess to
which you are referring. Especially compared to the thrash of moving
our test baseline.
People will not be running your test baseline, mind you. They will be
running the product of merging that with other stuff and for example
the same change showing as two different commits in the history is not
a particularly clean thing.