Rusty Russell ru...@rustcorp.com.au wrote:
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.
Ah, okay. In that case, zap it and see if anyone
David Howells dhowe...@redhat.com writes:
Rusty Russell ru...@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,
Rusty Russell ru...@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?
macro VIRTIO_PCI_CONFIG except in the unlikely event userspace
actually has a structure with a field named msix_enabled.
Get the msix_enabled by value instead, to make it useful
for userspace.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/virtio/virtio_pci.c | 8
Michael S. Tsirkin m...@redhat.com writes:
macro VIRTIO_PCI_CONFIG except in the unlikely event userspace
actually has a structure with a field named msix_enabled.
Get the msix_enabled by value instead, to make it useful
for userspace.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Macro
