linux-kernel - Re: [PATCH 02/15] libnvdimm: infrastructure for btt devices

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:	Tue, 23 Jun 2015 12:19:17 +0200
From:	Christoph Hellwig <hch@....de>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	Jeff Moyer <jmoyer@...hat.com>, Christoph Hellwig <hch@....de>,
	Jens Axboe <axboe@...nel.dk>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...1.01.org>,
	Neil Brown <neilb@...e.de>,
	Greg KH <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Linux ACPI <linux-acpi@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 02/15] libnvdimm: infrastructure for btt devices

On Mon, Jun 22, 2015 at 12:02:54PM -0700, Dan Williams wrote:
> I don't see the need to re-invent partitioning which is the path this
> requested rework is putting us on...
> 
> However, when the need arises for smaller granularity BTT we can have
> the partition fight then.  To be clear, I believe that need is already
> here today, but I'm not in a position to push that agenda at this late
> date.


Instead of all this complaining and moaning let's figure out what
architecture you'd actually want.  The one I had in mind is:

+------------------------------+
|  block layer (& partitions)  |
+---------------+--------------+--------------------+
|  pmem driver  |  btt driver  |  other consumers   |
+---------------+--------------+--------------------+
|        pmem API through libnvdimm                 |
+---------------------------------------------------+

If you really want btt to stack on top of pmem it really
needs to be moved out entirely of libnvdimm and be a
generic block driver just using ->rw_bytes, e.g.:


+------------------------------+
|  btt driver                  |
+------------------------------+
|  block layer (& partitions)  |
+------------------------------+--------------------+
|  pmem driver                 | other consumers    |
+------------------------------+--------------------+
|        pmem API through libnvdimm                 |
+---------------------------------------------------+

Not the current mess where btt pretends to be a stacking block
driver but still ties into libnvdimm.

Add blk mode access to all the schemes, but it's really just
another next to the pmem driver each time.  In fact while
looking over the code a bit more I start to wonder why
we need the blk driver at all - just hook into the nfit
do_io routines instead of the low-level API based on what
libnvdimm provides, and don't offer DAX for it.  It mostly
seems duplicate code.
--
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/