Re: [PATCH] fuse: use kernel headers when __KERNEL__ is set

[Colin Cross]

On Wed, Apr 17, 2013 at 2:57 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> On Tue, Apr 16, 2013 at 01:00:37PM -0700, Colin Cross wrote:
>
>> Every other uapi header includes linux/types.h to get its type
>> definitions, and fuse.h should do the same when compiling for
>> userspace targeting linux
>
> Not necessarily.
>
> Here's a patch (largish but only search&replace) that should fix all the issues
> and actually removes a hack instead of adding more.
>
> Thanks,
> Miklos
> ----
>
> From: Miklos Szeredi <mszeredi@xxxxxxx>
> Subject: fuse: fix type definitions in uapi header
>
> Commit 7e98d53086d18c877cb44e9065219335184024de (Synchronize fuse
> header with one used in library) added #ifdef __linux__ around
> defines if it is not set.  The kernel build is self-contained and
> can be built on non-Linux toolchains.  After the mentioned commit
> builds on non-Linux toolchains will try to include stdint.h and
> fail due to -nostdinc, and then fail with a bunch of undefined
> type errors.
>
> Fix by checking for __KERNEL__ instead of __linux__ and using the standard int
> types instead of the linux specific ones.
>
> Reported-by: Arve Hjønnevåg <arve@xxxxxxxxxxx>
> Reported-by: Colin Cross <ccross@xxxxxxxxxxx>
> Signed-off-by: Miklos Szeredi <mszeredi@xxxxxxx>

This fixes my build issue, and doesn't introduce a new make
headers_check warning so you can add my Tested-by: Colin Cross
<ccross@xxxxxxxxxxx>

I still like my patch better though.  This patch results in different
typedefs being used when compiling in userspace vs. kernel, so you're
trusting that the host stdint.h matches the kernel's definitions.  In
practice I don't see how they would differ, so I guess its up to you.
If it were up to me, I would use linux/types.h for kernel and linux
userspace, and maybe replace the #defines with typedefs for non-linux
userspace builds.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/