[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in port

From: Bryan Venteicher
Subject: Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code
Date: Wed, 29 May 2013 00:17:02 -0500

On Mon, May 27, 2013 at 6:15 AM, Rusty Russell <address@hidden> wrote:
Anthony Liguori <address@hidden> writes:
> Paolo Bonzini <address@hidden> writes:
>> Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>>> > My fault.  I should have looked at linux/types.h (actually asm-generic/).
>>> Not really, __uX appear in the headers that were posted.
> Which is a problem because this is a reserved namespace in C99.

Personally, I find it hard to care.  What matters is not what the
standard has carved out, but whether we have clashes, reserved namespace
or no.  And that won't happen for these.

If someone wants to convert all the kernel headers, I won't NAK it

> Perhaps it's even worth moving the headers from uapi/linux to
> uapi/virtio.  Rusty, what do you think?

Hmm, #include <virtio/virtio_net.h> etc would be worthwhile if that also
worked on FreeBSD.  Bryan CC'd...

I've only done minor work on the VirtIO headers when importing them to FreeBSD - mostly converting the _XX types to the preferred C99 variants, along with some misc nits. I'm not too concerned with keeping the headers identical to what is in Linux; I manually merge in required changes when supporting a new feature and this hasn't been an issue. I'm content as long as they remain BSD licensed. Growing GPL'ed #includes is a bit worrisome, but I have a hard time foreseeing what the VirtIO files could possibly depend on that isn't trivial.

I don't think I have enough context to understand the  ' #include <virtio/virtio_net.h> etc' suggestion ... In FreeBSD, the VirtIO headers files exist only in the source tree along side the corresponding device, ie. sys/dev/virtio/network/virtio_net.h, sys/dev/virtio/pci/virtio_pci.h, etc. The FreeBSD hypervisor (bhyve) just duplicates the needed definitions/defines. This will be fixed at some point, but bhyve's VirtIO is so barebones there is bigger fish to fry.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]