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. >