From: Rusty Russell <rusty@rustcorp.com.au>
Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, dhowells@redhat.com,
Dave Jones <davej@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Stephen Hemminger <shemminger@vyatta.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] virtio_pci: fix macro exported in uapi
Date: Mon, 20 May 2013 09:38:25 +0930 [thread overview]
Message-ID: <87r4h2zf5y.fsf@rustcorp.com.au> (raw)
In-Reply-To: <32418.1368781063@warthog.procyon.org.uk>
David Howells <dhowells@redhat.com> writes:
> Rusty Russell <rusty@rustcorp.com.au> wrote:
>
>> Macro still isn't usable, because userspace can't know whether it's the
>> new or old.
>>
>> We need to either remove it from UAPI, or rename it to
>> VIRTIO_PCI_CONFIG_OFF.
>
> Surely, if userspace is using it as is, you can't remove it, rename it or
> alter it?
The point of the patch is that it's unusable:
#define VIRTIO_PCI_CONFIG(dev) ((dev)->msix_enabled ? 24 : 20)
ie. it's accessing a member of the kernel's virtio_pci_dev structure.
In theory, userspace could have a structure with the same field and be
using it now, but that's unlikely (qemu certainly doesn't). No harm no
foul.
In theory it's actually a useful macro, so we could expose it to
userspace, but we'd need to have a new name so userspace can #ifdef for
older headers...
Hope that clarifies,
Rusty.
WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: David Howells <dhowells@redhat.com>
Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, dhowells@redhat.com,
Dave Jones <davej@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Stephen Hemminger <shemminger@vyatta.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] virtio_pci: fix macro exported in uapi
Date: Mon, 20 May 2013 09:38:25 +0930 [thread overview]
Message-ID: <87r4h2zf5y.fsf@rustcorp.com.au> (raw)
In-Reply-To: <32418.1368781063@warthog.procyon.org.uk>
David Howells <dhowells@redhat.com> writes:
> Rusty Russell <rusty@rustcorp.com.au> wrote:
>
>> Macro still isn't usable, because userspace can't know whether it's the
>> new or old.
>>
>> We need to either remove it from UAPI, or rename it to
>> VIRTIO_PCI_CONFIG_OFF.
>
> Surely, if userspace is using it as is, you can't remove it, rename it or
> alter it?
The point of the patch is that it's unusable:
#define VIRTIO_PCI_CONFIG(dev) ((dev)->msix_enabled ? 24 : 20)
ie. it's accessing a member of the kernel's virtio_pci_dev structure.
In theory, userspace could have a structure with the same field and be
using it now, but that's unlikely (qemu certainly doesn't). No harm no
foul.
In theory it's actually a useful macro, so we could expose it to
userspace, but we'd need to have a new name so userspace can #ifdef for
older headers...
Hope that clarifies,
Rusty.
WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: David Howells <dhowells@redhat.com>
Cc: dhowells@redhat.com, "Michael S. Tsirkin" <mst@redhat.com>,
kvm@vger.kernel.org, Stephen Hemminger <shemminger@vyatta.com>,
Jason Wang <jasowang@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Dave Jones <davej@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] virtio_pci: fix macro exported in uapi
Date: Mon, 20 May 2013 09:38:25 +0930 [thread overview]
Message-ID: <87r4h2zf5y.fsf@rustcorp.com.au> (raw)
In-Reply-To: <32418.1368781063@warthog.procyon.org.uk>
David Howells <dhowells@redhat.com> writes:
> Rusty Russell <rusty@rustcorp.com.au> wrote:
>
>> Macro still isn't usable, because userspace can't know whether it's the
>> new or old.
>>
>> We need to either remove it from UAPI, or rename it to
>> VIRTIO_PCI_CONFIG_OFF.
>
> Surely, if userspace is using it as is, you can't remove it, rename it or
> alter it?
The point of the patch is that it's unusable:
#define VIRTIO_PCI_CONFIG(dev) ((dev)->msix_enabled ? 24 : 20)
ie. it's accessing a member of the kernel's virtio_pci_dev structure.
In theory, userspace could have a structure with the same field and be
using it now, but that's unlikely (qemu certainly doesn't). No harm no
foul.
In theory it's actually a useful macro, so we could expose it to
userspace, but we'd need to have a new name so userspace can #ifdef for
older headers...
Hope that clarifies,
Rusty.
next prev parent reply other threads:[~2013-05-20 0:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-16 16:44 [PATCH] virtio_pci: fix macro exported in uapi Michael S. Tsirkin
2013-05-16 16:44 ` Michael S. Tsirkin
2013-05-17 0:09 ` Rusty Russell
2013-05-17 0:09 ` Rusty Russell
2013-05-17 8:57 ` David Howells
2013-05-17 8:57 ` David Howells
2013-05-20 0:08 ` Rusty Russell [this message]
2013-05-20 0:08 ` Rusty Russell
2013-05-20 0:08 ` Rusty Russell
2013-05-20 9:06 ` David Howells
2013-05-20 9:06 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r4h2zf5y.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=davej@redhat.com \
--cc=dhowells@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=shemminger@vyatta.com \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.