Jonathan Cameron wrote: > On Mon, 14 Apr 2025 21:50:31 -0700 > Dan Williams <dan.j.willi...@intel.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.
