linux-kernel - Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 21 Dec 2016 18:25:58 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     kvm@...r.kernel.org,
        Radim Krčmář <rkrcmar@...hat.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, devel@...uxdriverproject.org,
        Ingo Molnar <mingo@...hat.com>,
        Roman Kagan <rkagan@...tuozzo.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Denis V . Lunev" <den@...nvz.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi

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