From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43701) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhYld-00018K-VH for qemu-devel@nongnu.org; Wed, 29 May 2013 01:17:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhYlS-0005aq-88 for qemu-devel@nongnu.org; Wed, 29 May 2013 01:17:45 -0400 Received: from mail-ie0-x22f.google.com ([2607:f8b0:4001:c03::22f]:47138) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhYlS-0005al-12 for qemu-devel@nongnu.org; Wed, 29 May 2013 01:17:34 -0400 Received: by mail-ie0-f175.google.com with SMTP id tp5so6840926ieb.6 for ; Tue, 28 May 2013 22:17:33 -0700 (PDT) MIME-Version: 1.0 Sender: mr.kodiak@gmail.com In-Reply-To: <87ehcsptbg.fsf@rustcorp.com.au> References: <1369581694-1655-1-git-send-email-mst@redhat.com> <20130526175110.GA3115@redhat.com> <20130526181017.GB3115@redhat.com> <51A253C6.7060303@redhat.com> <20130526183747.GB3427@redhat.com> <51A25A2D.8030700@redhat.com> <20130526200251.GA4305@redhat.com> <51A26E95.5000207@redhat.com> <878v314gb2.fsf@codemonkey.ws> <87ehcsptbg.fsf@rustcorp.com.au> From: Bryan Venteicher Date: Wed, 29 May 2013 00:17:02 -0500 Message-ID: Content-Type: multipart/alternative; boundary=047d7b414098c2730504ddd47f7f Subject: Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rusty Russell Cc: Peter Maydell , "Michael S. Tsirkin" , qemu-devel@nongnu.org, virtualization , Anthony Liguori , Paolo Bonzini --047d7b414098c2730504ddd47f7f Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 27, 2013 at 6:15 AM, Rusty Russell wrote: > Anthony Liguori writes: > > Paolo Bonzini 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 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 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. > --047d7b414098c2730504ddd47f7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Mon, May 27, 2013 at 6:15 AM, Rusty Russell <rusty@rustcorp.com.au<= /a>> wrote:
Anthony Liguori <anthony@codemonkey.ws> writes:
> Paolo Bonzini <pbonzini@redhat.com> writes:
>
>> Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>>> > My fault. =A0I should have looked at linux/types.h (actua= lly 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. =A0What matters is not what the
standard has carved out, but whether we have clashes, reserved namespace or no. =A0And 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. =A0Rusty, what do you think?

Hmm, #include <virtio/virtio_net.h> etc would be worthwhile if that a= lso
worked on FreeBSD. =A0Bryan CC'd...


I've only done minor work on the V= irtIO headers when importing them to FreeBSD - mostly converting the _XX ty= pes to the=A0preferred=A0C99 variants, along with some misc nits. I'm n= ot too concerned with keeping the headers=A0identical=A0to what is in Linux= ; I manually merge in required changes when supporting a new feature and th= is hasn't been an issue.=A0I'm content as long as they remain BSD l= icensed. Growing GPL'ed #includes is a bit worrisome, but I have a hard= time=A0foreseeing=A0what the VirtIO files could=A0possibly=A0depend on tha= t isn't=A0trivial.

I don't think I have enough context to understand t= he =A0'=A0#include <virtio/virtio_net.h> etc' suggestion ... = In FreeBSD, the VirtIO headers files exist only in the source tree along si= de the=A0corresponding=A0device, ie. sys/dev/virtio/network/virtio_net.h, s= ys/dev/virtio/pci/virtio_pci.h, etc. The FreeBSD hypervisor (bhyve) just du= plicates the needed=A0definitions/defines. This will be fixed at some point= , but bhyve's VirtIO is so barebones there is bigger fish to fry.
=A0
Cheers,
Rusty.

--047d7b414098c2730504ddd47f7f--