All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Christoph Hellwig <hch@lst.de>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	Boaz Harrosh <boaz@plexistor.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Neil Brown <neilb@suse.de>, Dave Chinner <david@fromorbit.com>,
	Lv Zheng <lv.zheng@intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Robert Moore <robert.moore@intel.com>,
	Ingo Molnar <mingo@kernel.org>,
	Linux ACPI <linux-acpi@vger.kernel.org>,
	jmoyer <jmoyer@redhat.com>,
	Nicholas Moulin <nicholas.w.moulin@linux.intel.com>,
	Matthew Wilcox <willy@linux.intel.com>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	Vishal Verma <vishal.l.verma@linux.intel.com>,
	Jens Axboe <axboe@fb.com>, Borislav Petkov <bp@alien8.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jens Axboe <axboe@kernel.dk>,
	Greg KH <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	linux-api@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v6 00/21] libnvdimm: non-volatile memory devices
Date: Wed, 17 Jun 2015 10:28:07 -0700	[thread overview]
Message-ID: <CAPcyv4j-f+vSF5QXNy5RrqW-pXNg1dKeusGvcBFhz8ygLnSFig@mail.gmail.com> (raw)
In-Reply-To: <20150617112654.GA9246@lst.de>

On Wed, Jun 17, 2015 at 4:26 AM, Christoph Hellwig <hch@lst.de> wrote:
> Still not a big fan of the spec, but I guess this is a mosly reasonable
> implementation now.
>
> So for patches 1-16:
>
> Acked-by: Christoph Hellwig <hch@lst.de>

Thanks Christoph!

> The btt integration still needs a proper patch split and review, and

Ok, I'll split all the patches that are dependent on ->rw_bytes() to
their own series, and break out the introduction of ->rw_bytes() to be
patch1 of that series.

> I still detest the mess with the test moduly by heart.

The only remaining risk I see of merging this is that it requires
someone making changes to either the libnvdimm implementation or the
routines being mocked (ioremap, __request_region, etc...) to think
through the implications to the unit test.  That's a maintenance
burden given that mocked interfaces are deliberately working around
base assumptions.  At a minimum I need to document what rules the
__wrap_* routines in tools/testing/nvdimm/test/iomap.c are violating
and why.

I'm not convinced that the maintenance burden overshadows the benefit
of having this infrastructure readily available.  It is the primary
reason we've been able to iterate the code with confidence at this
velocity and magnitude of feedback.

WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Christoph Hellwig <hch@lst.de>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	Boaz Harrosh <boaz@plexistor.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Neil Brown <neilb@suse.de>, Dave Chinner <david@fromorbit.com>,
	Lv Zheng <lv.zheng@intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Robert Moore <robert.moore@intel.com>,
	Ingo Molnar <mingo@kernel.org>,
	Linux ACPI <linux-acpi@vger.kernel.org>,
	jmoyer <jmoyer@redhat.com>,
	Nicholas Moulin <nicholas.w.moulin@linux.intel.com>,
	Matthew Wilcox <willy@linux.intel.com>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	Vishal Verma <vishal.l.verma@linux.intel.com>,
	Jens Axboe <axboe@fb.com>, Borislav Petkov <bp@alien8.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jens Axboe <axboe@kernel.dk>,
	Greg KH
	<gregkh@linuxfoundation.org>"linux-kernel@vger.kernel.org" <l>
Subject: Re: [PATCH v6 00/21] libnvdimm: non-volatile memory devices
Date: Wed, 17 Jun 2015 10:28:07 -0700	[thread overview]
Message-ID: <CAPcyv4j-f+vSF5QXNy5RrqW-pXNg1dKeusGvcBFhz8ygLnSFig@mail.gmail.com> (raw)
In-Reply-To: <20150617112654.GA9246@lst.de>

On Wed, Jun 17, 2015 at 4:26 AM, Christoph Hellwig <hch@lst.de> wrote:
> Still not a big fan of the spec, but I guess this is a mosly reasonable
> implementation now.
>
> So for patches 1-16:
>
> Acked-by: Christoph Hellwig <hch@lst.de>

Thanks Christoph!

> The btt integration still needs a proper patch split and review, and

Ok, I'll split all the patches that are dependent on ->rw_bytes() to
their own series, and break out the introduction of ->rw_bytes() to be
patch1 of that series.

> I still detest the mess with the test moduly by heart.

The only remaining risk I see of merging this is that it requires
someone making changes to either the libnvdimm implementation or the
routines being mocked (ioremap, __request_region, etc...) to think
through the implications to the unit test.  That's a maintenance
burden given that mocked interfaces are deliberately working around
base assumptions.  At a minimum I need to document what rules the
__wrap_* routines in tools/testing/nvdimm/test/iomap.c are violating
and why.

I'm not convinced that the maintenance burden overshadows the benefit
of having this infrastructure readily available.  It is the primary
reason we've been able to iterate the code with confidence at this
velocity and magnitude of feedback.

WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Christoph Hellwig <hch@lst.de>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
	Boaz Harrosh <boaz@plexistor.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Neil Brown <neilb@suse.de>, Dave Chinner <david@fromorbit.com>,
	Lv Zheng <lv.zheng@intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Robert Moore <robert.moore@intel.com>,
	Ingo Molnar <mingo@kernel.org>,
	Linux ACPI <linux-acpi@vger.kernel.org>,
	jmoyer <jmoyer@redhat.com>,
	Nicholas Moulin <nicholas.w.moulin@linux.intel.com>,
	Matthew Wilcox <willy@linux.intel.com>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	Vishal Verma <vishal.l.verma@linux.intel.com>,
	Jens Axboe <axboe@fb.com>, Borislav Petkov <bp@alien8.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jens Axboe <axboe@kernel.dk>,
	Greg KH <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	linux-api@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v6 00/21] libnvdimm: non-volatile memory devices
Date: Wed, 17 Jun 2015 10:28:07 -0700	[thread overview]
Message-ID: <CAPcyv4j-f+vSF5QXNy5RrqW-pXNg1dKeusGvcBFhz8ygLnSFig@mail.gmail.com> (raw)
In-Reply-To: <20150617112654.GA9246@lst.de>

On Wed, Jun 17, 2015 at 4:26 AM, Christoph Hellwig <hch@lst.de> wrote:
> Still not a big fan of the spec, but I guess this is a mosly reasonable
> implementation now.
>
> So for patches 1-16:
>
> Acked-by: Christoph Hellwig <hch@lst.de>

Thanks Christoph!

> The btt integration still needs a proper patch split and review, and

Ok, I'll split all the patches that are dependent on ->rw_bytes() to
their own series, and break out the introduction of ->rw_bytes() to be
patch1 of that series.

> I still detest the mess with the test moduly by heart.

The only remaining risk I see of merging this is that it requires
someone making changes to either the libnvdimm implementation or the
routines being mocked (ioremap, __request_region, etc...) to think
through the implications to the unit test.  That's a maintenance
burden given that mocked interfaces are deliberately working around
base assumptions.  At a minimum I need to document what rules the
__wrap_* routines in tools/testing/nvdimm/test/iomap.c are violating
and why.

I'm not convinced that the maintenance burden overshadows the benefit
of having this infrastructure readily available.  It is the primary
reason we've been able to iterate the code with confidence at this
velocity and magnitude of feedback.

  reply	other threads:[~2015-06-17 17:28 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-11 20:09 [PATCH v6 00/21] libnvdimm: non-volatile memory devices Dan Williams
2015-06-11 20:09 ` Dan Williams
2015-06-11 20:10 ` [PATCH v6 01/21] e820, efi: add ACPI 6.0 persistent memory types Dan Williams
2015-06-11 20:10   ` Dan Williams
2015-06-11 20:10   ` Dan Williams
2015-06-11 20:10 ` [PATCH v6 02/21] libnvdimm, nfit: initial libnvdimm infrastructure and NFIT support Dan Williams
2015-06-11 20:10   ` Dan Williams
2015-06-11 20:10   ` Dan Williams
2015-06-17 21:59   ` Rafael J. Wysocki
2015-06-17 21:59     ` Rafael J. Wysocki
2015-06-17 21:35     ` Dan Williams
2015-06-17 21:35       ` Dan Williams
2015-06-17 21:35       ` Dan Williams
2015-06-11 20:10 ` [PATCH v6 03/21] libnvdimm: control character device and nvdimm_bus sysfs attributes Dan Williams
2015-06-11 20:10   ` Dan Williams
2015-06-11 20:10   ` Dan Williams
2015-06-17 22:00   ` Rafael J. Wysocki
2015-06-17 22:00     ` Rafael J. Wysocki
2015-06-17 22:00     ` Rafael J. Wysocki
2015-06-11 20:10 ` [PATCH v6 04/21] libnvdimm, nfit: dimm/memory-devices Dan Williams
2015-06-11 20:10   ` Dan Williams
2015-06-17 22:02   ` Rafael J. Wysocki
2015-06-17 22:02     ` Rafael J. Wysocki
2015-06-11 20:10 ` [PATCH v6 05/21] libnvdimm: control (ioctl) messages for nvdimm_bus and nvdimm devices Dan Williams
2015-06-11 20:10   ` Dan Williams
2015-06-11 20:10 ` [PATCH v6 06/21] libnvdimm, nvdimm: dimm driver and base libnvdimm device-driver infrastructure Dan Williams
2015-06-11 20:10   ` Dan Williams
2015-06-11 20:10 ` [PATCH v6 07/21] libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory) Dan Williams
2015-06-11 20:10   ` Dan Williams
2015-06-11 20:10   ` Dan Williams
2015-06-17 22:03   ` Rafael J. Wysocki
2015-06-17 22:03     ` Rafael J. Wysocki
2015-06-11 20:10 ` [PATCH v6 08/21] libnvdimm: support for legacy (non-aliasing) nvdimms Dan Williams
2015-06-11 20:10   ` Dan Williams
2015-06-11 20:10 ` [PATCH v6 09/21] libnvdimm, pmem: move pmem to drivers/nvdimm/ Dan Williams
2015-06-11 20:10   ` Dan Williams
2015-06-11 20:10   ` Dan Williams
2015-06-11 20:11 ` [PATCH v6 10/21] libnvdimm, pmem: add libnvdimm support to the pmem driver Dan Williams
2015-06-11 20:11   ` Dan Williams
2015-06-11 20:11 ` [PATCH v6 11/21] libnvdimm, nfit: add interleave-set state-tracking infrastructure Dan Williams
2015-06-11 20:11   ` Dan Williams
2015-06-11 20:11   ` Dan Williams
2015-06-17 22:06   ` Rafael J. Wysocki
2015-06-17 22:06     ` Rafael J. Wysocki
2015-06-11 20:11 ` [PATCH v6 12/21] libnvdimm: namespace indices: read and validate Dan Williams
2015-06-11 20:11   ` Dan Williams
2015-06-11 20:11 ` [PATCH v6 13/21] libnvdimm: pmem label sets and namespace instantiation Dan Williams
2015-06-11 20:11   ` Dan Williams
2015-06-11 20:11 ` [PATCH v6 14/21] libnvdimm: blk labels " Dan Williams
2015-06-11 20:11   ` Dan Williams
2015-06-11 20:11 ` [PATCH v6 15/21] libnvdimm: write pmem label set Dan Williams
2015-06-11 20:11   ` Dan Williams
2015-06-11 20:11 ` [PATCH v6 16/21] libnvdimm: write blk " Dan Williams
2015-06-11 20:11   ` Dan Williams
2015-06-11 20:11 ` [PATCH v6 17/21] libnvdimm: infrastructure for btt devices Dan Williams
2015-06-11 20:11   ` Dan Williams
2015-06-17 10:49   ` Christoph Hellwig
2015-06-17 10:49     ` Christoph Hellwig
2015-06-17 10:49     ` Christoph Hellwig
2015-06-11 20:11 ` [PATCH v6 18/21] nd_btt: atomic sector updates Dan Williams
2015-06-11 20:11   ` Dan Williams
2015-06-11 20:22   ` Dan Williams
2015-06-11 20:22     ` Dan Williams
2015-06-11 20:11 ` [PATCH v6 19/21] libnvdimm, nfit, nd_blk: driver for BLK-mode access persistent memory Dan Williams
2015-06-11 20:11   ` Dan Williams
2015-06-17 22:09   ` Rafael J. Wysocki
2015-06-17 22:09     ` Rafael J. Wysocki
2015-06-17 22:09     ` Rafael J. Wysocki
2015-06-11 20:11 ` [PATCH v6 20/21] tools/testing/nvdimm: libnvdimm unit test infrastructure Dan Williams
2015-06-11 20:11   ` Dan Williams
2015-06-11 20:12 ` [PATCH v6 21/21] libnvdimm: Non-Volatile Devices Dan Williams
2015-06-11 20:12   ` Dan Williams
2015-06-17 11:26 ` [PATCH v6 00/21] libnvdimm: non-volatile memory devices Christoph Hellwig
2015-06-17 11:26   ` Christoph Hellwig
2015-06-17 11:26   ` Christoph Hellwig
2015-06-17 17:28   ` Dan Williams [this message]
2015-06-17 17:28     ` Dan Williams
2015-06-17 17:28     ` Dan Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPcyv4j-f+vSF5QXNy5RrqW-pXNg1dKeusGvcBFhz8ygLnSFig@mail.gmail.com \
    --to=dan.j.williams@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@fb.com \
    --cc=axboe@kernel.dk \
    --cc=boaz@plexistor.com \
    --cc=bp@alien8.de \
    --cc=david@fromorbit.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=hpa@zytor.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=luto@amacapital.net \
    --cc=lv.zheng@intel.com \
    --cc=mingo@kernel.org \
    --cc=neilb@suse.de \
    --cc=nicholas.w.moulin@linux.intel.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rafael@kernel.org \
    --cc=robert.moore@intel.com \
    --cc=ross.zwisler@linux.intel.com \
    --cc=sfr@canb.auug.org.au \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vishal.l.verma@linux.intel.com \
    --cc=willy@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.