From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933959AbdABTja (ORCPT ); Mon, 2 Jan 2017 14:39:30 -0500 Received: from mail-pg0-f54.google.com ([74.125.83.54]:35707 "EHLO mail-pg0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933935AbdABTjZ (ORCPT ); Mon, 2 Jan 2017 14:39:25 -0500 Date: Mon, 2 Jan 2017 11:39:16 -0800 From: Stephen Hemminger To: Roman Kagan Cc: KY Srinivasan , Christoph Hellwig , Paolo Bonzini , Radim =?UTF-8?B?S3LEjW3DocWZ?= , Vitaly Kuznetsov , "kvm@vger.kernel.org" , "Denis V . Lunev" , Haiyang Zhang , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , Ingo Molnar , "H. Peter Anvin" , "devel@linuxdriverproject.org" , Thomas Gleixner Subject: Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi Message-ID: <20170102113916.22c0251e@xeon-e3> In-Reply-To: <20161228170943.GB14702@rkaganb.sw.ru> References: <20161221062939.GB15917@rkaganb.sw.ru> <20161221121858.GA17429@infradead.org> <20161221125920.GG15917@rkaganb.sw.ru> <20161221142654.GB8594@infradead.org> <20161221154348.GA31401@infradead.org> <20161221095049.6fdc3145@xeon-e3> <20161221175836.GA8846@infradead.org> <20161221100247.69a4049b@xeon-e3> <20161228170943.GB14702@rkaganb.sw.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v02JelYi018803 On Wed, 28 Dec 2016 20:09:44 +0300 Roman Kagan wrote: > On Wed, Dec 21, 2016 at 07:54:11PM +0000, KY Srinivasan wrote: > > > > > > > -----Original Message----- > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > > Sent: Wednesday, December 21, 2016 10:03 AM > > > To: Christoph Hellwig > > > Cc: Paolo Bonzini ; Roman Kagan > > > ; Radim Krčmář ; KY > > > Srinivasan ; Vitaly Kuznetsov > > > ; kvm@vger.kernel.org; Denis V . Lunev > > > ; Haiyang Zhang ; > > > x86@kernel.org; linux-kernel@vger.kernel.org; Ingo Molnar > > > ; H. Peter Anvin ; > > > devel@linuxdriverproject.org; Thomas Gleixner > > > Subject: Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi > > > > > > On Wed, 21 Dec 2016 09:58:36 -0800 > > > Christoph Hellwig wrote: > > > > > > > On Wed, Dec 21, 2016 at 09:50:49AM -0800, Stephen Hemminger wrote: > > > > > Lastly, there is licensing issues on headers. It would be good to have any > > > > > userspace ABI headers licensed with a more liberal license so that BSD > > > and DPDK drivers > > > > > could use them directly. Right now each one reinvents. > > > > > > > > Microsoft could easily solves this problem by offering a suitably > > > > liberally licensed header documenting the full HyperV guest protocol > > > > that Linux and other projects could use. > > > > > > The issue is if same header file mixes kernel and userspace API stuff. > > > > > > Once the files are arranged right, I will submit trivial change to comments > > > to indicate the liberal licensing of userspace API headers. > > > > Let us take this one step at a time. I know for a fact that not all the guest host > > protocols on Hyper-V are guaranteed to be stable. Some of the protocols are part of > > the published MSFT standards such RNDIS and these obviously are guaranteed to be > > stable. For the rest it is less clear. The fact that we need to ensure compatibility of existing > > Windows guests tells me that any host side changes will be versioned and the hosts will always > > support older guests. > > > > I would like to minimize what we include in the uapi header; especially when MSFT has made no guarantees > > with regards how they may be evolved. I will also work on getting some clarity on both stability and > > under what license we would expose the uapi header. > > Am I correct assuming that QEMU is currently the only user of > arch/x86/include/uapi/asm/hyperv.h? > > Then I think we're fine withdrawing it from uapi as a whole and letting > QEMU pull it in through its header-harvesting scripts (as does now > anyway). This would lift all licensing and longterm API stability > expectations. > > Roman. Thanks, that prevents lots of problems. That is how I handle iproute2 as well.