Thread (14 messages) 14 messages, 4 authors, 2013-05-29

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

From: Anthony Liguori <hidden>
Date: 2013-05-27 00:55:37
Also in: qemu-devel

"Michael S. Tsirkin" [off-list ref] writes:
On Sun, May 26, 2013 at 03:49:53PM -0500, Anthony Liguori wrote:
quoted
Paolo Bonzini [off-list ref] writes:
quoted
Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
quoted
quoted
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.
quoted
quoted
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.
quoted
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.
quoted
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
quoted
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
quoted
Paolo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help