Ben Widawsky <ben.widaw...@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.widaw...@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