linux-kernel - Re: [PATCH v9 00/19] DCD: Add support for Dynamic Capacity Devices (DCD)

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] [day] [month] [year] [list]

Message-ID: <67fe9b44b7663_71fe2947b@dwillia2-xfh.jf.intel.com.notmuch>
Date: Tue, 15 Apr 2025 10:45:40 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>, Dan Williams
	<dan.j.williams@...el.com>
CC: Ira Weiny <ira.weiny@...el.com>, Dave Jiang <dave.jiang@...el.com>, Fan Ni
	<fan.ni@...sung.com>, Davidlohr Bueso <dave@...olabs.net>, Alison Schofield
	<alison.schofield@...el.com>, Vishal Verma <vishal.l.verma@...el.com>,
	<linux-cxl@...r.kernel.org>, <nvdimm@...ts.linux.dev>,
	<linux-kernel@...r.kernel.org>, Li Ming <ming.li@...omail.com>
Subject: Re: [PATCH v9 00/19] DCD: Add support for Dynamic Capacity Devices
 (DCD)

Jonathan Cameron wrote:
> On Mon, 14 Apr 2025 21:50:31 -0700
> Dan Williams <dan.j.williams@...el.com> wrote:
> 
> > Jonathan Cameron wrote:
> > [..]
> > > To me we don't need to answer the question of whether we fully understand
> > > requirements, or whether this support covers them, but rather to ask
> > > if anyone has requirements that are not sensible to satisfy with additional
> > > work building on this?  
> > 
> > Wearing only my upstream kernel development hat, the question for
> > merging is "what is the end user visible impact of merging this?". As
> > long as DCD remains in proof-of-concept mode then leave the code out of
> > tree until it is ready to graduate past that point.
> 
> Hi Dan,
> 
> Seems like we'll have to disagree on this. The only thing I can
> therefore do is help to keep this patch set in a 'ready to go' state.
> 
> I would ask that people review it with that in mind so that we can
> merge it the day someone is willing to announce a product which
> is a lot more about marketing decisions than anything technical.
> Note that will be far too late for distro cycles so distro folk
> may have to pick up the fork (which they will hate).

This is overstated. Distros say "no" to supporting even *shipping*
hardware when there is insufficient customer pull through.  If none of
the distros' customers can get their hands on DCD hardware that
contraindicates merge and distro intercept decisions.

> Hopefully that 'fork' will provide a base on which we can build
> the next set of key features. 

They are only key features when the adoption approaches inevitability.
The LSF/MM discussions around the ongoing challenges of managing
disparate performance memory pools still has me uneasy about whether
Linux yet has the right ABI in hand for dedicated-memory.

What folks seems to want is an anon-only memory provider that does not
ever leak into kernel allocations, and optionally a filesystem
abstraction to provide file backed allocation of dedicate memory. What
they do not want is to teach their applications anything beyond
"malloc()" for anon.

[..]
> That is (at least partly) because the ecosystem for those was initially BIOS
> only. That's not true for DCD. So people built devices on basis they didn't
> need any kernel support.  Lots of disadvantages to that but it's what happened.
> As a side note, I'd much rather that path had never been there as it is
> continuing to make a mess for Gregory and others.

The mess is driven by insufficient communication between platform
firmware implementations and Linux expectations. That is a tractable
problem.