From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757848AbdACJcM (ORCPT ); Tue, 3 Jan 2017 04:32:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59060 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752671AbdACJcK (ORCPT ); Tue, 3 Jan 2017 04:32:10 -0500 Subject: Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi To: Stephen Hemminger , Roman Kagan 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> <20170102113916.22c0251e@xeon-e3> Cc: KY Srinivasan , Christoph Hellwig , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , 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 From: Paolo Bonzini Message-ID: Date: Tue, 3 Jan 2017 10:32:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170102113916.22c0251e@xeon-e3> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 03 Jan 2017 09:32:10 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/01/2017 20:39, Stephen Hemminger wrote: >>> >>> 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. > > Thanks, that prevents lots of problems. > That is how I handle iproute2 as well. Except it wouldn't work. But no big deal, I guess we'll just synchronize hyperv.h manually. :(( Paolo