netdev - Re: [PATCH v9 06/27] cxl: add function for type2 cxl regs setup

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: <6791809bdbdce_20fa29452@dwillia2-xfh.jf.intel.com.notmuch>
Date: Wed, 22 Jan 2025 15:34:51 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Alejandro Lucero Palau <alucerop@....com>, Dan Williams
	<dan.j.williams@...el.com>, <alejandro.lucero-palau@....com>,
	<linux-cxl@...r.kernel.org>, <netdev@...r.kernel.org>, <edward.cree@....com>,
	<davem@...emloft.net>, <kuba@...nel.org>, <pabeni@...hat.com>,
	<edumazet@...gle.com>, <dave.jiang@...el.com>
Subject: Re: [PATCH v9 06/27] cxl: add function for type2 cxl regs setup

Alejandro Lucero Palau wrote:
[..]
> > Apologies for that, I had not looked at the implications of that general
> > decision until now, but the result is going in the wrong direction from
> > what it is doing to the core.
> 
> After yesterday's meeting listening to Jonathan and you discussing last 
> reviews, what I thought was mainly related to this patchset, I was not 
> sure I had to address this concern, but it is clear now.
> 
> I'm a bit disappointed this requiring new design after so many cycles 
> and about something I thought it was set and consensus existed.

That is valid frustration, and there was indeed long silence on this
patchset from me until recently.

> Anyway, I'll work on that, not sure yet what I should change and what 
> should stay, because the main reason for the current design of an accel 
> driver API does not exist anymore.

Yes, I think this was the main disconnect. The CXL core is a library,
the expander use case is supported by a class code, the accelerator use
case is an a la carte subset plus some disjoint bits. The library should
be use case agnostic.

That means that accelerator specific exports should be avoided
especially when they are just wrapping other existing library exports.
Push the use case specific concerns to the leaf drivers.

Another way to put it is that new exports from drivers/cxl/ and core
data structure touches will receive higher scrutiny, because that is new
maintenance burden on the core.

> I need time for figuring out the work to do, so DCD should take priority 
> now for trying to merge it with 6.14.

This is all a bit too late unfortunately and I do not want to pressure
Dave to explain to Linus why patches are still flowing into the CXL tree
during the merge window.

Lets get this wrapped up and in cxl.next early in the v6.15 cycle.