From: Jonathan Cameron Subject: Re: Fostering linux community collaboration on hardware accelerators Date: Mon, 16 Oct 2017 15:07:01 +0100 Message-ID: <20171016150701.00004260@huawei.com> References: <201710101132.v9ABUs28138304@mx0a-001b2d01.pphosted.com> <07d49485-e583-8434-5681-92a0b54005ca@au1.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: , "Liguozhu (Kenneth)" , "Ilias Apalodimas" , , , , Alex Williamson , Frederic Barrat , Mark Brown , , , Ard Biesheuvel , "Jean-Philippe Brucker" , Kirti Wankhede , Eric Auger , , , To: Andrew Donnellan Return-path: In-Reply-To: <07d49485-e583-8434-5681-92a0b54005ca@au1.ibm.com> Sender: kvm-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org > > So as ever with a linux community focusing on a particular topic, the > > obvious solution is a mailing list. There are a number of options on how > > do this. > > > > 1) Ask one of the industry bodies to host? Who? > > > > 2) Put together a compelling argument for linux-accelerators@vger.kernel.org > > as probably the most generic location for such a list. > > Happy to offer linux-accelerators@lists.ozlabs.org, which I can get set > up immediately (and if we want patchwork, patchwork.ozlabs.org is > available as always, no matter where the list is hosted). > That would be great! Thanks for doing this. Much easier to find out what such a list is useful for by the practical option of having a list and see what people do with it. Thanks, Jonathan > > More open questions are > > 1) Scope? > > * Would anyone ever use such an overarching list? > > * Are we better off with the usual adhoc list of 'interested parties' + lkml? > > * Do we actually need to define the full scope - are we better with a vague > > definition? > > I think a list with a broad and vaguely defined scope is a good idea - > it would certainly be helpful to us to be able to follow what other > contributors are doing that could be relevant to our CAPI and OpenCAPI work. > > > > > 2) Is there an existing community we can use to discuss these issues? > > (beyond the obvious firehose of LKML). > > > > 3) Who else to approach for input on these general questions? > > > > In parallel to this there are elements such as git / patchwork etc but > > they can all be done as they are needed. > > > > Thanks > > > > -- > > Jonathan Cameron > > Huawei > > >