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

[Michael S. Tsirkin]

On Sun, May 26, 2013 at 08:26:14PM +0200, Paolo Bonzini wrote:
> Il 26/05/2013 20:10, Michael S. Tsirkin ha scritto:
> > On Sun, May 26, 2013 at 07:00:58PM +0100, Peter Maydell wrote:
> >> On 26 May 2013 18:51, Michael S. Tsirkin <address@hidden> wrote:
> >>> On Sun, May 26, 2013 at 04:43:57PM +0100, Peter Maydell wrote:
> >>>> This series breaks compilation on MacOSX:
> >>>>
> >>>>   CC    net/eth.o
> >>>> In file included from net/eth.c:18:
> >>>> In file included from /Users/pm215/src/qemu/include/net/eth.h:29:
> >>>> /Users/pm215/src/qemu/linux-headers/linux/if_ether.h:24:10: fatal
> >>>> error: 'linux/types.h' file not found
> >>>> #include <linux/types.h>
> >>>>          ^
> >>>> 1 error generated.
> >>>> make: *** [net/eth.o] Error 1
> >>
> >>> Could be a stale file in your tree ...
> >>> Did configure get re-run?
> >>> Could you post the config-host.mak file please?
> >>
> >> Configure did get rerun, but where are you expecting the header
> >> to pull linux/types.h from?  Your patchset adds files which include
> >> it but doesn't add any copy itself, so if you're not on a Linux
> >> host then it just doesn't exist...
> >>
> >> config-host.mak attached.
> >>
> >> thanks
> >> -- PMM
> > 
> > 
> > Ouch. Forgot to git-add them. Thanks.
> > 
> > I'll send a fixed version -
> > could you please try this patch on top?
> > 
> > 
> >     linux-stubs: linux/types.h
> >     
> >     This adds a directory with minimal stubs that
> >     make it possible to use some linux headers
> >     in qemu in a portable environment.
> >     
> >     Signed-off-by: Michael S. Tsirkin <address@hidden>
> > 
> > ---
> > 
> > diff --git a/linux-stubs/linux/types.h b/linux-stubs/linux/types.h
> > new file mode 100644
> > index 0000000..8642cbb
> > --- /dev/null
> > +++ b/linux-stubs/linux/types.h
> > @@ -0,0 +1,37 @@
> > +#ifndef STUBS_LINUX_TYPES_H
> > +#define STUBS_LINUX_TYPES_H
> > +
> > +#include <stdint.h>
> > +
> > +/*
> > + * Below are Linux-specific types that should never collide with
> > + * any application/library that wants linux/types.h.
> > + */
> > +
> > +typedef uint8_t __u8;
> > +typedef uint16_t __u16;
> > +typedef uint32_t __u32;
> > +typedef uint64_t __u64;
> > +
> > +#ifdef __CHECKER__
> > +#define __bitwise__ __attribute__((bitwise))
> > +#else
> > +#define __bitwise__
> > +#endif
> > +#ifdef __CHECK_ENDIAN__
> > +#define __bitwise __bitwise__
> > +#else
> > +#define __bitwise
> > +#endif
> > +
> > +typedef __u16 __bitwise __le16;
> > +typedef __u16 __bitwise __be16;
> > +typedef __u32 __bitwise __le32;
> > +typedef __u32 __bitwise __be32;
> > +typedef __u64 __bitwise __le64;
> > +typedef __u64 __bitwise __be64;
> > +
> > +typedef __u16 __bitwise __sum16;
> > +typedef __u32 __bitwise __wsum;
> > +
> 
> I don't like defining __-prefixed types.  Can we preprocess
> linux-headers to avoid usage of __u8/16/32/64, and to
> s,linux/types.h,stdint.h, ?
> 
> Paolo

Let's not be purists, and do the practical thing.

When I suggested this you didn't like it:
>> I can think of two ways:
>>     - strip linux/types.h in update_headers
>>     - add a stub linux/types.h for non linux platforms
>
>The latter, using stdint.h types, would be fine.

And now, I think it's cleaner to keep it as is.
Most likely, these specific __ types work fine, *if* we
see a problem we can think what's to be done.
In particular, there are __le/__be tags there which can
be useful to do static code analysis.

What's the worst case failure scanario?
Conflict with some system standard header on some
strange target OS, this results in a failed build,
and we go and try to fix it, almost surely with
ifndef around some of the stubs. Why worry now?

> > +#endif
> > 
> > 
> >