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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
