Re: Follow-up on the CXL discussion at OFTC

["Alex Bennée" <alex.bennee@linaro.org>]

Ben Widawsky <ben.widawsky@intel.com> writes:

> On 21-11-19 02:29:51, Shreyas Shah wrote:
>> Hi Ben
>> 
>> Are you planning to add the CXL2.0 switch inside QEMU or already added in one of the version? 
>>  
>
> From me, there are no plans for QEMU anything until/unless upstream thinks it
> will merge the existing patches, or provide feedback as to what it would take to
> get them merged. If upstream doesn't see a point in these patches, then I really
> don't see much value in continuing to further them. Once hardware comes out, the
> value proposition is certainly less.

I take it:

  Subject: [RFC PATCH v3 00/31] CXL 2.0 Support
  Date: Mon,  1 Feb 2021 16:59:17 -0800
  Message-Id: <20210202005948.241655-1-ben.widawsky@intel.com>

is the current state of the support? I saw there was a fair amount of
discussion on the thread so assumed there would be a v4 forthcoming at
some point.

Adding new subsystems to QEMU does seem to be a pain point for new
contributors. Patches tend to fall through the cracks of existing
maintainers who spend most of their time looking at stuff that directly
touches their files. There is also a reluctance to merge large chunks of
functionality without an identified maintainer (and maybe reviewers) who
can be the contact point for new patches. So in short you need:

 - Maintainer Reviewed-by/Acked-by on patches that touch other sub-systems
 - Reviewed-by tags on the new sub-system patches from anyone who understands CXL
 - Some* in-tree testing (so it doesn't quietly bitrot)
 - A patch adding the sub-system to MAINTAINERS with identified people

* Some means at least ensuring qtest can instantiate the device and not
  fall over. Obviously more testing is better but it can always be
  expanded on in later series.

Is that the feedback you were looking for?

-- 
Alex Bennée