| Message ID | 20161220155602.6298-13-rkagan@virtuozzo.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, 20 Dec 2016 18:55:59 +0300 Roman Kagan <rkagan@virtuozzo.com> wrote: > Userspace will need them too. > > Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> What userspace? I am worried about creating more stable API's that can't change. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 20, 2016 at 09:25:43AM -0800, Stephen Hemminger wrote: > On Tue, 20 Dec 2016 18:55:59 +0300 > Roman Kagan <rkagan@virtuozzo.com> wrote: > > > Userspace will need them too. > > > > Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> > > What userspace? I am worried about creating more stable API's that can't change. QEMU in particular. We're planning to implement VMBus devices in QEMU and would like to have the definitions shared with the Linux guest drivers for Hyper-V. Roman. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 21, 2016 at 09:29:39AM +0300, Roman Kagan wrote: > QEMU in particular. We're planning to implement VMBus devices in QEMU > and would like to have the definitions shared with the Linux guest > drivers for Hyper-V. And that's everything but a userspace API. The way to go for protocol constants is to have a normal kernel header that is not exported, and a copy of it wherever else you need it. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 21, 2016 at 04:18:58AM -0800, Christoph Hellwig wrote: > On Wed, Dec 21, 2016 at 09:29:39AM +0300, Roman Kagan wrote: > > QEMU in particular. We're planning to implement VMBus devices in QEMU > > and would like to have the definitions shared with the Linux guest > > drivers for Hyper-V. > > And that's everything but a userspace API. The way to go for protocol > constants is to have a normal kernel header that is not exported, and > a copy of it wherever else you need it. That's fine by me. I guess the series should then start with a complete move arch/x86/include/uapi/asm/hyperv.h -> arch/x86/include/asm/hyperv_proto.h, and the remaining patches have to change the latter instead of the former? Thanks, Roman. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 21, 2016 at 03:59:20PM +0300, Roman Kagan wrote: > That's fine by me. > > I guess the series should then start with a complete move > arch/x86/include/uapi/asm/hyperv.h -> > arch/x86/include/asm/hyperv_proto.h, and the remaining patches have to > change the latter instead of the former? That would be my preference, but we'll need to figure out why hyperv has ever been a UABI header, and if anyone is using it. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 21, 2016 at 06:26:54AM -0800, Christoph Hellwig wrote: > On Wed, Dec 21, 2016 at 03:59:20PM +0300, Roman Kagan wrote: > > That's fine by me. > > > > I guess the series should then start with a complete move > > arch/x86/include/uapi/asm/hyperv.h -> > > arch/x86/include/asm/hyperv_proto.h, and the remaining patches have to > > change the latter instead of the former? > > That would be my preference, but we'll need to figure out why > hyperv has ever been a UABI header, and if anyone is using it. It was initially done by my former teammate, and I guess only QEMU (outside kernel) is using some of it. Roman. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 21/12/2016 15:26, Christoph Hellwig wrote: > On Wed, Dec 21, 2016 at 03:59:20PM +0300, Roman Kagan wrote: >> That's fine by me. >> >> I guess the series should then start with a complete move >> arch/x86/include/uapi/asm/hyperv.h -> >> arch/x86/include/asm/hyperv_proto.h, and the remaining patches have to >> change the latter instead of the former? > > That would be my preference, but we'll need to figure out why > hyperv has ever been a UABI header, and if anyone is using it. QEMU uses it, but we already bundle the header files and update them periodically from the files that Linux installs. So any change in Linux would not break the QEMU build; having the header in UAPI is convenient but I guess our update scripts could do whatever Linux's scripts/headers_install.sh does. That said, there are precedents in using UAPI this way for PV interfaces. See for example include/uapi/linux/virtio*.h and arch/x86/include/uapi/asm/kvm_para.h. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 21, 2016 at 04:39:18PM +0100, Paolo Bonzini wrote: > That said, there are precedents in using UAPI this way for PV > interfaces. See for example include/uapi/linux/virtio*.h and > arch/x86/include/uapi/asm/kvm_para.h. We have all kinds of historical examples, but most of them turned into a major pain sooner or later - my favourite example are the SCSI protocol headers. Protocols needs to stay compatible on the (virtual) wire, but not on the language level. Locking us into the strict UABI policies for them just make someone life horrible further down the road. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 21/12/2016 16:43, Christoph Hellwig wrote: > On Wed, Dec 21, 2016 at 04:39:18PM +0100, Paolo Bonzini wrote: >> That said, there are precedents in using UAPI this way for PV >> interfaces. See for example include/uapi/linux/virtio*.h and >> arch/x86/include/uapi/asm/kvm_para.h. > > We have all kinds of historical examples, but most of them turned > into a major pain sooner or later - my favourite example are the > SCSI protocol headers. Mine too, and because of how uapi/ was created there are quite a few such historical headers (my favourite is cuda.h, just because of the name). > Protocols needs to stay compatible on the (virtual) wire, but not > on the language level. Locking us into the strict UABI policies > for them just make someone life horrible further down the road. The ABI for this kind of thing is not changing much anyway, because it's the hardware or processor or (as in this case) hypervisor ABI. The more interesting question is about the API, and here in the end it seems to be up to the maintainer. Some have explicitly asked to move stuff *out* of UAPI, for example the x86 guys have removed msr-index.h from UAPI recently. Others are okay with it and they simply aren't strict on cleanups that might break the *programming* interface, as in patch 15 of this series. See for example pci_regs.h commit 846fc70986a6, "PCI/AER: Rename PCI_ERR_UNC_TRAIN to PCI_ERR_UNC_UND", everybody just moved on and QEMU adjusted its use of PCI_ERR_UNC_TRAIN. Having this in UAPI has been convenient for QEMU, but of course the kernel couldn't care less. So if KY prefers to have the header outside UAPI, we will just follow suit... Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 21 Dec 2016 07:43:48 -0800 Christoph Hellwig <hch@infradead.org> wrote: > On Wed, Dec 21, 2016 at 04:39:18PM +0100, Paolo Bonzini wrote: > > That said, there are precedents in using UAPI this way for PV > > interfaces. See for example include/uapi/linux/virtio*.h and > > arch/x86/include/uapi/asm/kvm_para.h. > > We have all kinds of historical examples, but most of them turned > into a major pain sooner or later - my favourite example are the > SCSI protocol headers. > > Protocols needs to stay compatible on the (virtual) wire, but not > on the language level. Locking us into the strict UABI policies > for them just make someone life horrible further down the road. If the the protocols come from external sources (like the current NDIS definitions), then it is not a big deal. There is some overlap already where NDIS is used multiple places and there are multiple header files with same definition. That could be fixed. The bigger problem is that some of the API's between guest and host could be implemented multiple ways and don't want userspace ABI files constraining how something like atomic bit operation for wakeup is done. The other problem with the hyperv headers is they were initially done with only the Linux driver usage in mind. This made perfect sense at the time, the problem is that they mix internal state with protocol definitions. 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 21/12/2016 18:50, Stephen Hemminger wrote: > The other problem with the hyperv headers is they were initially done with > only the Linux driver usage in mind. This made perfect sense at the time, > the problem is that they mix internal state with protocol definitions. Yes, and this was partly fixed when KVM started to use some of those definitions too (the implementation of Hyper-V protocols is split between kernel and userspace). > 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. Other projects are using sanitized userspace ABI headers just fine, so this is something that lawyers should sort out before kernel hackers do. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----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. Regards, K. Y -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. That makes sense, but if it is not in uapi then any changes may break QEMU in future (without regret). If QEMU is diving in and extracting non UAPI headers then that is a bad idea. It is outside the scope of this. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 28/12/2016 18:09, Roman Kagan wrote: > 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. Actually, QEMU's header-harvesting scripts use uapi/ headers exclusively, since they are built on "make headers_install". The extra cleanups that QEMU does on top are to allow compilation of the headers on non-Linux machines. They don't really do much more than changing Linux (linux/types.h) integer types to the C99 (stdint.h) equivalents. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote: > On 28/12/2016 18:09, Roman Kagan wrote: > > 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. > > Actually, QEMU's header-harvesting scripts use uapi/ headers > exclusively, since they are built on "make headers_install". > > The extra cleanups that QEMU does on top are to allow compilation of the > headers on non-Linux machines. They don't really do much more than > changing Linux (linux/types.h) integer types to the C99 (stdint.h) > equivalents. Ouch, I stand corrected. So what should we do with it then? I'm sorta lost... We certainly can give it up and live with a private copy of the definitions in the QEMU tree but that doesn't sound optimal in any sense. Thanks, Roman. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On January 9, 2017 12:32:23 AM PST, Roman Kagan <rkagan@virtuozzo.com> wrote: >On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote: >> On 28/12/2016 18:09, Roman Kagan wrote: >> > 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. >> >> Actually, QEMU's header-harvesting scripts use uapi/ headers >> exclusively, since they are built on "make headers_install". >> >> The extra cleanups that QEMU does on top are to allow compilation of >the >> headers on non-Linux machines. They don't really do much more than >> changing Linux (linux/types.h) integer types to the C99 (stdint.h) >> equivalents. > >Ouch, I stand corrected. > >So what should we do with it then? I'm sorta lost... > >We certainly can give it up and live with a private copy of the >definitions in the QEMU tree but that doesn't sound optimal in any >sense. > >Thanks, >Roman. Why do that through header mangling rather than typedef?
On Mon, Jan 09, 2017 at 12:40:48AM -0800, hpa@zytor.com wrote: > On January 9, 2017 12:32:23 AM PST, Roman Kagan <rkagan@virtuozzo.com> wrote: > >On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote: > >> On 28/12/2016 18:09, Roman Kagan wrote: > >> > 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. > >> > >> Actually, QEMU's header-harvesting scripts use uapi/ headers > >> exclusively, since they are built on "make headers_install". > >> > >> The extra cleanups that QEMU does on top are to allow compilation of > >the > >> headers on non-Linux machines. They don't really do much more than > >> changing Linux (linux/types.h) integer types to the C99 (stdint.h) > >> equivalents. > > > >Ouch, I stand corrected. > > > >So what should we do with it then? I'm sorta lost... > > > >We certainly can give it up and live with a private copy of the > >definitions in the QEMU tree but that doesn't sound optimal in any > >sense. > > > >Thanks, > >Roman. > > Why do that through header mangling rather than typedef? Sorry for not being clear, I actually asked what to do with the Hyper-V and VMBus protocol definitions. The typedef vs mangling is a different matter; I guess mangling was chosen to avoid conflicts with system-provided definitions on non-Linux systems, but I think Paolo can tell more. Roman. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/01/2017 09:40, hpa@zytor.com wrote: > On January 9, 2017 12:32:23 AM PST, Roman Kagan <rkagan@virtuozzo.com> wrote: >> On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote: >>> On 28/12/2016 18:09, Roman Kagan wrote: >>>> 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. >>> >>> Actually, QEMU's header-harvesting scripts use uapi/ headers >>> exclusively, since they are built on "make headers_install". >>> >>> The extra cleanups that QEMU does on top are to allow compilation of >> the >>> headers on non-Linux machines. They don't really do much more than >>> changing Linux (linux/types.h) integer types to the C99 (stdint.h) >>> equivalents. >> >> Ouch, I stand corrected. >> >> So what should we do with it then? I'm sorta lost... >> >> We certainly can give it up and live with a private copy of the >> definitions in the QEMU tree but that doesn't sound optimal in any >> sense. > > Why do that through header mangling rather than typedef? Because you are not suppose to typedef identifiers that start with "__", and because it does do a few other ad-hoc changes: -e 's/<linux\/\([^>]*\)>/"standard-headers\/linux\/\1"/' \ -e 's/__bitwise__//' \ -e 's/__attribute__((packed))/QEMU_PACKED/' \ -e 's/__inline__/inline/' \ -e '/sys\/ioctl.h/d' \ -e 's/SW_MAX/SW_MAX_/' \ Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/x86/include/uapi/asm/hyperv.h b/arch/x86/include/uapi/asm/hyperv.h index e081615..5d6e525 100644 --- a/arch/x86/include/uapi/asm/hyperv.h +++ b/arch/x86/include/uapi/asm/hyperv.h @@ -419,4 +419,13 @@ struct hv_monitor_page { __u8 rsvdz4[1984]; }; +/* VMBus expects pre-established communication with the following IDs */ +#define VMBUS_MESSAGE_CONNECTION_ID 1 +#define VMBUS_MESSAGE_PORT_ID 1 +#define VMBUS_EVENT_CONNECTION_ID 2 +#define VMBUS_EVENT_PORT_ID 2 +#define VMBUS_MONITOR_CONNECTION_ID 3 +#define VMBUS_MONITOR_PORT_ID 3 +#define VMBUS_MESSAGE_SINT 2 + #endif diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h index 7f247f2..c0a65f7 100644 --- a/drivers/hv/hyperv_vmbus.h +++ b/drivers/hv/hyperv_vmbus.h @@ -114,16 +114,6 @@ enum hv_guest_os_microsoft_ids { }; -enum { - VMBUS_MESSAGE_CONNECTION_ID = 1, - VMBUS_MESSAGE_PORT_ID = 1, - VMBUS_EVENT_CONNECTION_ID = 2, - VMBUS_EVENT_PORT_ID = 2, - VMBUS_MONITOR_CONNECTION_ID = 3, - VMBUS_MONITOR_PORT_ID = 3, - VMBUS_MESSAGE_SINT = 2, -}; - /* #defines */ #define HV_PRESENT_BIT 0x80000000
Userspace will need them too. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- arch/x86/include/uapi/asm/hyperv.h | 9 +++++++++ drivers/hv/hyperv_vmbus.h | 10 ---------- 2 files changed, 9 insertions(+), 10 deletions(-)