Thread (130 messages) 130 messages, 10 authors, 2020-03-12

Re: [PATCH v3 00/27] Add support for OpenCAPI Persistent Memory devices

From: "Oliver O'Halloran" <oohall@gmail.com>
Date: 2020-02-24 06:51:47
Also in: linux-mm, lkml, nvdimm

On Mon, Feb 24, 2020 at 3:43 PM Alastair D'Silva [off-list ref] wrote:
On Sun, 2020-02-23 at 20:37 -0800, Matthew Wilcox wrote:
quoted
On Mon, Feb 24, 2020 at 03:34:07PM +1100, Alastair D'Silva wrote:
quoted
V3:
  - Rebase against next/next-20200220
  - Move driver to arch/powerpc/platforms/powernv, we now expect
this
    driver to go upstream via the powerpc tree
That's rather the opposite direction of normal; mostly drivers live
under
drivers/ and not in arch/.  It's easier for drivers to get overlooked
when doing tree-wide changes if they're hiding.
This is true, however, given that it was not all that desirable to have
it under drivers/nvdimm, it's sister driver (for the same hardware) is
also under arch, and that we don't expect this driver to be used on any
platform other than powernv, we think this was the most reasonable
place to put it.
Historically powernv specific platform drivers go in their respective
subsystem trees rather than in arch/ and I'd prefer we kept it that
way. When I added the papr_scm driver I put it in the pseries platform
directory because most of the pseries paravirt code lives there for
some reason; I don't know why. Luckily for me that followed the same
model that Dan used when he put the NFIT driver in drivers/acpi/ and
the libnvdimm core in drivers/nvdimm/ so we didn't have anything to
argue about. However, as Matthew pointed out, it is at odds with how
most subsystems operate. Is there any particular reason we're doing
things this way or should we think about moving libnvdimm users to
drivers/nvdimm/?

Oliver
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help