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

[Anthony Liguori]

"Michael S. Tsirkin" <address@hidden> writes:

> On Sun, May 26, 2013 at 03:49:53PM -0500, Anthony Liguori wrote:
>> 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.
>> 
>> >> 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 <linux/types.h>
>>     #else
>>     #include <stdint.h>
>>     #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