From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uglim-0005Mw-ID for qemu-devel@nongnu.org; Sun, 26 May 2013 20:55:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uglih-0001lu-Kl for qemu-devel@nongnu.org; Sun, 26 May 2013 20:55:32 -0400 Received: from mail-ob0-x233.google.com ([2607:f8b0:4003:c01::233]:33990) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uglih-0001lq-G9 for qemu-devel@nongnu.org; Sun, 26 May 2013 20:55:27 -0400 Received: by mail-ob0-f179.google.com with SMTP id wo10so3945503obc.24 for ; Sun, 26 May 2013 17:55:26 -0700 (PDT) From: Anthony Liguori In-Reply-To: <20130526214213.GB4828@redhat.com> References: <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> <20130526214213.GB4828@redhat.com> Date: Sun, 26 May 2013 19:55:25 -0500 Message-ID: <87txlp1bsy.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: "Michael S. Tsirkin" Cc: Paolo Bonzini , Rusty Russell , virtualization , qemu-devel@nongnu.org, Peter Maydell "Michael S. Tsirkin" writes: > On Sun, May 26, 2013 at 03:49:53PM -0500, Anthony Liguori wrote: >> 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. >> >> >> What I'm saying is - a chance of a conflict is very remote, >> >> if it happens it's a build failure so easy to debug. >> > >> > I'm sure that others will complain, :) but you can go ahead. >> >> I think we should clean up the virtio headers in the kernel first. >> Seems like a good thing to do given the standardization effort too. >> There are lots of headers in uapi that use the C99 int types > > I found 4: > $ grep -l uint include/uapi/linux/*h > include/uapi/linux/dm-log-userspace.h > include/uapi/linux/fuse.h > include/uapi/linux/jffs2.h > include/uapi/linux/pps.h > include/uapi/linux/rds.h > include/uapi/linux/sctp.h > > That's not really lots. > >> so there >> doesn't seem to be a reason they couldn't be used in virtio. fuse.h >> even has a: >> >> #ifdef __KERNEL__ >> #include >> #else >> #include >> #endif >> >> Which seems like a reasonable thing to do. > > In kernel, we really want to use things like endian-ness > checks (and, we really should have them in userspace too!). > So we want __le32 and other kernel goodies > like that. stdint.h won't cut it. With the spec being standardized, I think having a stand alone set of headers is a good thing. Licensing is problematic here too. If virtio headers depend on other Linux headers, then it really doesn't matter if they are BSD licensed if you need a GPL header (like linux/if_ether.h). Now, we can certainly debate the copyrightability of these defines and what have you but if the headers are meant to be 1) consumed outside the kernel 2) licensed under a different license than the general kernel then depending on kernel goodies is the wrong strategy. >> The only other kernel dependency is linux/if_ether.h to define >> ETH_ALEN. But it seems completely reasonable to define a >> VIRTIO_NET_MAC_ALEN or something like that. > > Ugh. Not really reasonable IMO. We also use ETH_P_IP in code, > would like to get rid of redefining that too. > But we can have our own linux/if_ether.h for non-linux hosts, > just with a > couple of macros like that, it's not a big deal. See above. Regards, Anthony Liguori > >> This would make the virtio headers completely stand alone and includable >> in userspace (without violating C99). >> >> Perhaps it's even worth moving the headers from uapi/linux to >> uapi/virtio. Rusty, what do you think? >> >> Regards, >> >> Anhtony Liguori >> >> > >> > Paolo