linux-kernel - Re: [GIT PULL v4 00/21] libnd: non-volatile memory device support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 May 2015 15:52:37 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	"Rafael J. Wysocki" <rafael@...nel.org>
Cc:	Jens Axboe <axboe@...nel.dk>, Boaz Harrosh <boaz@...xistor.com>,
	Neil Brown <neilb@...e.de>, Dave Chinner <david@...morbit.com>,
	Lv Zheng <lv.zheng@...el.com>,
	"H. Peter Anvin" <hpa@...or.com>, Christoph Hellwig <hch@....de>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Robert Moore <robert.moore@...el.com>,
	Ingo Molnar <mingo@...nel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	jmoyer <jmoyer@...hat.com>,
	Nicholas Moulin <nicholas.w.moulin@...ux.intel.com>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	Vishal Verma <vishal.l.verma@...ux.intel.com>,
	Jens Axboe <axboe@...com>, Borislav Petkov <bp@...en8.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [GIT PULL v4 00/21] libnd: non-volatile memory device support

On Wed, May 27, 2015 at 3:36 PM, Rafael J. Wysocki <rafael@...nel.org> wrote:
> Hi,
>
> On Thu, May 28, 2015 at 12:24 AM, Dan Williams <dan.j.williams@...el.com> wrote:
>> Jens, please pull from...
>>
>>    git://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm tags/libnd-for-jens
>>
>> ...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(-)
>>     https://lists.01.org/pipermail/linux-nvdimm/2015-April/000484.html
>>
>> v2: 30 files changed, 3166 insertions(+), 3935 deletions(-)
>>     https://lists.01.org/pipermail/linux-nvdimm/2015-April/000574.html
>>
>> v3: 33 files changed, 2202 insertions(+), 1233 deletions(-)
>>     https://lists.01.org/pipermail/linux-nvdimm/2015-May/000804.html
>>
>> 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?

> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/