Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754501AbcLUUJ4 (ORCPT ); Wed, 21 Dec 2016 15:09:56 -0500 Received: from mail-by2nam03on0119.outbound.protection.outlook.com ([104.47.42.119]:35593 "EHLO NAM03-BY2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752673AbcLUUJy (ORCPT ); Wed, 21 Dec 2016 15:09:54 -0500 From: KY Srinivasan To: Stephen Hemminger , Christoph Hellwig CC: Paolo Bonzini , Roman Kagan , =?iso-8859-2?Q?Radim_Kr=E8m=E1=F8?= , 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 Thread-Topic: [PATCH 12/15] hyperv: move VMBus connection ids to uapi Thread-Index: AQHSWtm3DzvTuJPK5kyIILG4ZrZve6ERFnuAgADbB4CAAGGZAIAAC0gAgAAYdwCAABQ6AIAAAUIAgAAjfYCAAAItAIAAASuAgAAaidA= Date: Wed, 21 Dec 2016 19:54:11 +0000 Message-ID: References: <20161220155602.6298-1-rkagan@virtuozzo.com> <20161220155602.6298-13-rkagan@virtuozzo.com> <20161220092543.6183bffd@xeon-e3> <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> In-Reply-To: <20161221100247.69a4049b@xeon-e3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kys@microsoft.com; x-originating-ip: [2601:600:8c00:1040:b076:3b2a:409c:285e] x-ms-office365-filtering-correlation-id: 4879ca72-bf33-43c2-d18b-08d429db2282 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR03MB1424; x-microsoft-exchange-diagnostics: 1;CY1PR03MB1424;7:sDf/+Z/mGwz7LVcuQdodGkhFzaSO5HlQBAzN66ZWU4BOU/nugpTfGOF96ySugXiJ5xCSjRFBZLwd40PYQ9+9DN3BwBHQiNiQ9o8WOxJERIsENIQG+HSJhWnfAO8LPv6GgwVIpKAxrWtbwCaZa88at1gVWy0x7sd3uJ8Wc4G186p/aG7cPWOIM/rmM0dL7MTHk2rPcIQgQNZ2nK3m4+k0eKlq2wNilqw0W9nSIwPuh8A1+PmzMtwBhVmdwsRfMrTnLbv7of1HmrR7kAaNnke7yRnYSOTtkBKAhbvMuUrGiHQpL6EOOeJH4YlmLLDK9f/FKBh+iSKik+VnLD8i0JEvnlRoktIqBNdztYY0u3Or2eR4jicuTbbjLbt54SmQiEW3H0tNYUoysSfH5mBTAWYm07zjRSLc8EYhZYNyDcGn+PpBAkWJ8Xxl+JcHecgGvDJkBGMVhW5VMZdwODkpv0hqz1qlzV66ielhzB0TM0sRu+w= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(9452136761055)(5213294742642); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148)(6047074);SRVR:CY1PR03MB1424;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB1424; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(39450400003)(39850400002)(39860400002)(39840400002)(39410400002)(13464003)(199003)(377454003)(189002)(24454002)(97736004)(3660700001)(76576001)(122556002)(106356001)(105586002)(5005710100001)(99286002)(8990500004)(3280700002)(10290500002)(106116001)(5001770100001)(189998001)(2906002)(4326007)(86362001)(86612001)(38730400001)(74316002)(2900100001)(6436002)(6116002)(77096006)(92566002)(68736007)(5660300001)(33656002)(102836003)(2950100002)(9686002)(93886004)(7696004)(305945005)(8936002)(7736002)(76176999)(10090500001)(81156014)(54356999)(50986999)(229853002)(81166006)(7416002)(6506006)(101416001)(8676002)(25786008);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR03MB1424;H:DM5PR03MB2490.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-2" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2016 19:54:11.7005 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB1424 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 uBLKA2IL006849 Content-Length: 2278 Lines: 48 > -----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. Regards, K. Y