Re: [PATCH] contrib/vhost-user-blk: Clean up deallocation of VuVirtqElement

From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Raphael Norwitz <raphael.norwitz@nutanix.com>,
	Markus Armbruster <armbru@redhat.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"qemu-trivial@nongnu.org" <qemu-trivial@nongnu.org>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH] contrib/vhost-user-blk: Clean up deallocation of VuVirtqElement
Date: Mon, 08 Aug 2022 15:37:19 +0100	[thread overview]
Message-ID: <87czdaoktd.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA_g-7uM3WN6ijL4RFcb5qRatX11vyeVvSwNHRNXbuAjgg@mail.gmail.com>

Peter Maydell <peter.maydell@linaro.org> writes:

> On Wed, 27 Jul 2022 at 18:28, Raphael Norwitz
> <raphael.norwitz@nutanix.com> wrote:
>>
>> On Tue, Jul 26, 2022 at 03:57:42PM +0100, Peter Maydell wrote:
>> > On Fri, 1 Jul 2022 at 06:41, Markus Armbruster <armbru@redhat.com> wrote:
>> > > Could we use a contrib/README with an explanation what "contrib" means,
>> > > and how to build and use the stuff there?
>> >
>> > I would rather we got rid of contrib/ entirely. Our git repo
>> > should contain things we care about enough to really support
>> > and believe in, in which case they should be in top level
>> > directories matching what they are (eg tools/). If we don't
>> > believe in these things enough to really support them, then
>> > we should drop them, and let those who do care maintain them
>> > as out-of-tree tools if they like.
>> >
>>
>> I can't speak for a lot of stuff in contrib/ but I find the vhost-user
>> backends like vhost-user-blk and vhost-user-scsi helpful for testing and
>> development. I would like to keep maintaining those two at least.
>
> Right, I don't mean we should just delete contrib/, but for the
> things currently in it that we do care about, we should define
> what their relationship to QEMU is and put them in a part of
> the source tree that says what they actually are. contrib/
> just means "nobody thought about it".

I split plugins a while ago between:

  tests/plugin
  contrib/plugins

where the former are really basic plugins that show usage, exercise the
API and are included in the check-tcg tests. The contrib plugins are
slightly more random mix of useful (e.g. cache, execlog), downright
experimental (lockstep) and stuff I can't actually test (e.g. drcov).

I'll quite happily continue to process patches that update and enhance
contrib/plugins but at a push a few could be promoted to less of a
dumping ground (tools/tcg-plugins?).

I guess it would only really matter if we were installing plugins as
part of "make install"?

-- 
Alex Bennée