On Mon, May 27, 2013 at 6:15 AM, Rusty Russell <ru...@rustcorp.com.au>wrote:

> Anthony Liguori <anth...@codemonkey.ws> writes:
> > Paolo Bonzini <pbonz...@redhat.com> 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
> though.
>
> > 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.


> Cheers,
> Rusty.
>

Reply via email to