lkml.org 
[lkml]   [2017]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 12/15] hyperv: move VMBus connection ids to uapi
    On Wed, 28 Dec 2016 20:09:44 +0300
    Roman Kagan <rkagan@virtuozzo.com> 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 <hch@infradead.org>
    > > > Cc: Paolo Bonzini <pbonzini@redhat.com>; Roman Kagan
    > > > <rkagan@virtuozzo.com>; Radim Krčmář <rkrcmar@redhat.com>; KY
    > > > Srinivasan <kys@microsoft.com>; Vitaly Kuznetsov
    > > > <vkuznets@redhat.com>; kvm@vger.kernel.org; Denis V . Lunev
    > > > <den@openvz.org>; Haiyang Zhang <haiyangz@microsoft.com>;
    > > > x86@kernel.org; linux-kernel@vger.kernel.org; Ingo Molnar
    > > > <mingo@redhat.com>; H. Peter Anvin <hpa@zytor.com>;
    > > > devel@linuxdriverproject.org; Thomas Gleixner <tglx@linutronix.de>
    > > > Subject: Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi
    > > >
    > > > On Wed, 21 Dec 2016 09:58:36 -0800
    > > > Christoph Hellwig <hch@infradead.org> 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.

    \
     
     \ /
      Last update: 2017-01-02 20:41    [W:3.868 / U:0.580 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site