linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] fuse: use kernel headers when __KERNEL__ is set
@ 2013-04-15 20:41 Colin Cross
  2013-04-15 21:47 ` Colin Cross
  0 siblings, 1 reply; 12+ messages in thread
From: Colin Cross @ 2013-04-15 20:41 UTC (permalink / raw)
  To: linux-kernel
  Cc: torvalds, Colin Cross, Miklos Szeredi, open list:FUSE: FILESYSTEM...

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.

Change the #ifdef to check for __linux__ or __KERNEL__ so that
it uses the kernel typedefs if __KERNEL__ is set.

Signed-off-by: Colin Cross <ccross@android.com>
---
I think this should go in v3.9, without it bare-metal toolchains
that don't define __linux__ will fail to compile the kernel, and
cross-compiles from non-linux hosts will probably also fail.

 include/uapi/linux/fuse.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
index 4c43b44..5b79443 100644
--- a/include/uapi/linux/fuse.h
+++ b/include/uapi/linux/fuse.h
@@ -95,7 +95,7 @@
 #ifndef _LINUX_FUSE_H
 #define _LINUX_FUSE_H
 
-#ifdef __linux__
+#if defined(__linux__) || defined(__KERNEL__)
 #include <linux/types.h>
 #else
 #include <stdint.h>
-- 
1.8.1.3


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [PATCH] fuse: use kernel headers when __KERNEL__ is set
  2013-04-15 20:41 [PATCH] fuse: use kernel headers when __KERNEL__ is set Colin Cross
@ 2013-04-15 21:47 ` Colin Cross
  2013-04-16 14:21   ` Miklos Szeredi
  0 siblings, 1 reply; 12+ messages in thread
From: Colin Cross @ 2013-04-15 21:47 UTC (permalink / raw)
  To: lkml
  Cc: Linus Torvalds, Colin Cross, Miklos Szeredi,
	open list:FUSE: FILESYSTEM...,
	Arve Hjønnevåg

On Mon, Apr 15, 2013 at 1:41 PM, Colin Cross <ccross@android.com> wrote:
> 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.
>
> Change the #ifdef to check for __linux__ or __KERNEL__ so that
> it uses the kernel typedefs if __KERNEL__ is set.
>
> Signed-off-by: Colin Cross <ccross@android.com>
> ---
> I think this should go in v3.9, without it bare-metal toolchains
> that don't define __linux__ will fail to compile the kernel, and
> cross-compiles from non-linux hosts will probably also fail.

Miklos, I see Arve sent an equivalent patch to you a month ago
(https://lkml.org/lkml/2013/3/11/620), and I agree with his response
to your question (checking for __linux__ and __KERNEL__ is better than
just checking for __KERNEL__ if you want this header to be used in
userspace builds on linux targets).  Can you pull one of these two
patches before 3.9?

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] fuse: use kernel headers when __KERNEL__ is set
  2013-04-15 21:47 ` Colin Cross
@ 2013-04-16 14:21   ` Miklos Szeredi
  2013-04-16 15:59     ` Linus Torvalds
  0 siblings, 1 reply; 12+ messages in thread
From: Miklos Szeredi @ 2013-04-16 14:21 UTC (permalink / raw)
  To: Colin Cross
  Cc: lkml, Linus Torvalds, open list:FUSE: FILESYSTEM...,
	Arve Hjønnevåg

On Mon, Apr 15, 2013 at 11:47 PM, Colin Cross <ccross@android.com> wrote:
> On Mon, Apr 15, 2013 at 1:41 PM, Colin Cross <ccross@android.com> wrote:
>> 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.
>>
>> Change the #ifdef to check for __linux__ or __KERNEL__ so that
>> it uses the kernel typedefs if __KERNEL__ is set.
>>
>> Signed-off-by: Colin Cross <ccross@android.com>
>> ---
>> I think this should go in v3.9, without it bare-metal toolchains
>> that don't define __linux__ will fail to compile the kernel, and
>> cross-compiles from non-linux hosts will probably also fail.
>
> Miklos, I see Arve sent an equivalent patch to you a month ago
> (https://lkml.org/lkml/2013/3/11/620), and I agree with his response
> to your question (checking for __linux__ and __KERNEL__ is better than
> just checking for __KERNEL__ if you want this header to be used in
> userspace builds on linux targets).

And I still disagree.  Why should userspace use the linux internal
header when there's a perfectly good standard header that it can use?

Patch committed and pushed to for-next and for-linus.  I'll push to
Linus tomorrow.

Thanks,
Miklos

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] fuse: use kernel headers when __KERNEL__ is set
  2013-04-16 14:21   ` Miklos Szeredi
@ 2013-04-16 15:59     ` Linus Torvalds
  2013-04-16 17:24       ` Miklos Szeredi
  0 siblings, 1 reply; 12+ messages in thread
From: Linus Torvalds @ 2013-04-16 15:59 UTC (permalink / raw)
  To: Miklos Szeredi
  Cc: Colin Cross, lkml, open list:FUSE: FILESYSTEM...,
	Arve Hjønnevåg

On Tue, Apr 16, 2013 at 7:21 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> And I still disagree.  Why should userspace use the linux internal
> header when there's a perfectly good standard header that it can use?

If it's called UAPI, it damn well is *meant* for user-space inclusion.
Look at the file-name.

And since the bug comment says "This file defines the kernel interface
of FUSE" *AND* it very clearly has explicit code to support user-space
includes with special user-space-only type defines, then your email is
obviously just pure crap, and I don't understand how you can write
that sentence with a straight face.

The *whole* point of the UAPI includes is two-fold:

 - to make it easier for user-space libraries to get at the kernel
definitions. Not everybody wants to use glibc for various reasons, and
where do you want people to *get* these declarations from?

 - to make kernel people more AWARE of when they are changing stuff
that affects user-space.

Now, the uapi model not perfect, but there are damn good reasons to at
least *strive* for both of those things, so I really don't understand
your comment there.

                Linus

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] fuse: use kernel headers when __KERNEL__ is set
  2013-04-16 15:59     ` Linus Torvalds
@ 2013-04-16 17:24       ` Miklos Szeredi
  2013-04-16 18:21         ` Linus Torvalds
  0 siblings, 1 reply; 12+ messages in thread
From: Miklos Szeredi @ 2013-04-16 17:24 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Colin Cross, lkml, open list:FUSE: FILESYSTEM...,
	Arve Hjønnevåg

On Tue, Apr 16, 2013 at 5:59 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Apr 16, 2013 at 7:21 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>>
>> And I still disagree.  Why should userspace use the linux internal
>> header when there's a perfectly good standard header that it can use?
>
> If it's called UAPI, it damn well is *meant* for user-space inclusion.
> Look at the file-name.
>
> And since the bug comment says "This file defines the kernel interface
> of FUSE" *AND* it very clearly has explicit code to support user-space
> includes with special user-space-only type defines, then your email is
> obviously just pure crap, and I don't understand how you can write
> that sentence with a straight face.

I think I meant something different by that sentence than what you
think I meant :)

What I meant is IF <linux/fuse.h> is included by userspace (it sure is
meant to be included and *is* included by libfuse and other stuff)
THEN using <stdint.h> instead of <linux/types.h> is fine regardless of
whether __linux__ is defined or not.

Does that sound better, or is there still something we disagree about?

Thanks,
Miklos

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] fuse: use kernel headers when __KERNEL__ is set
  2013-04-16 17:24       ` Miklos Szeredi
@ 2013-04-16 18:21         ` Linus Torvalds
  2013-04-16 18:29           ` Colin Cross
  0 siblings, 1 reply; 12+ messages in thread
From: Linus Torvalds @ 2013-04-16 18:21 UTC (permalink / raw)
  To: Miklos Szeredi
  Cc: Colin Cross, lkml, open list:FUSE: FILESYSTEM...,
	Arve Hjønnevåg

> What I meant is IF <linux/fuse.h> is included by userspace (it sure is
> meant to be included and *is* included by libfuse and other stuff)
> THEN using <stdint.h> instead of <linux/types.h> is fine regardless of
> whether __linux__ is defined or not.

That's probably true. But the patch in question adds the __KERNEL__
test, and *that* seems required.

If you think that we should instead drop the __linux__ test, than yes,
that part sounds fine. I thought that by "linux internal header" you
meant the fuse.h file, but you seem to mean the indirectly included
<inux/types.h>. That's fine.

                Linus

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] fuse: use kernel headers when __KERNEL__ is set
  2013-04-16 18:21         ` Linus Torvalds
@ 2013-04-16 18:29           ` Colin Cross
  2013-04-16 19:11             ` Miklos Szeredi
  0 siblings, 1 reply; 12+ messages in thread
From: Colin Cross @ 2013-04-16 18:29 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Miklos Szeredi, lkml, open list:FUSE: FILESYSTEM...,
	Arve Hjønnevåg

On Tue, Apr 16, 2013 at 11:21 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>> What I meant is IF <linux/fuse.h> is included by userspace (it sure is
>> meant to be included and *is* included by libfuse and other stuff)
>> THEN using <stdint.h> instead of <linux/types.h> is fine regardless of
>> whether __linux__ is defined or not.
>
> That's probably true. But the patch in question adds the __KERNEL__
> test, and *that* seems required.
>
> If you think that we should instead drop the __linux__ test, than yes,
> that part sounds fine. I thought that by "linux internal header" you
> meant the fuse.h file, but you seem to mean the indirectly included
> <inux/types.h>. That's fine.
>
>                 Linus

Dropping __linux__ causes a make headers_check warning, which the
kbuild test robot reported this morning:
usr/include/linux/fuse.h:99: found __[us]{8,16,32,64} type without
#include <linux/types.h>
Using my patch without modification does not cause that warning.

linux/types.h defines the types that are used to communicate between
the kernel and userspace.  Redefining those in each header makes no
sense, and will probably cause redefined types warnings if you compile
a userspace file that includes fuse.h and another uapi header that
properly includes linux/types.h.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] fuse: use kernel headers when __KERNEL__ is set
  2013-04-16 18:29           ` Colin Cross
@ 2013-04-16 19:11             ` Miklos Szeredi
  2013-04-16 20:00               ` Colin Cross
  0 siblings, 1 reply; 12+ messages in thread
From: Miklos Szeredi @ 2013-04-16 19:11 UTC (permalink / raw)
  To: Colin Cross
  Cc: Linus Torvalds, lkml, open list:FUSE: FILESYSTEM...,
	Arve Hjønnevåg

On Tue, Apr 16, 2013 at 8:29 PM, Colin Cross <ccross@android.com> wrote:
> Dropping __linux__ causes a make headers_check warning, which the
> kbuild test robot reported this morning:
> usr/include/linux/fuse.h:99: found __[us]{8,16,32,64} type without
> #include <linux/types.h>
> Using my patch without modification does not cause that warning.
>
> linux/types.h defines the types that are used to communicate between
> the kernel and userspace.  Redefining those in each header makes no
> sense, and will probably cause redefined types warnings if you compile
> a userspace file that includes fuse.h and another uapi header that
> properly includes linux/types.h.

<linux/types.h> is linux specific while the fuse API is cross
platform.  So the userspace header obviously has to use some cross
platform type definitions.  Making the type definitions depend on
__linux__ is probably just as unreliable in userspace as it is in the
kernel, so why complicate things with that?

Thanks,
Miklos

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] fuse: use kernel headers when __KERNEL__ is set
  2013-04-16 19:11             ` Miklos Szeredi
@ 2013-04-16 20:00               ` Colin Cross
  2013-04-17  9:57                 ` Miklos Szeredi
  0 siblings, 1 reply; 12+ messages in thread
From: Colin Cross @ 2013-04-16 20:00 UTC (permalink / raw)
  To: Miklos Szeredi
  Cc: Linus Torvalds, lkml, open list:FUSE: FILESYSTEM...,
	Arve Hjønnevåg

On Tue, Apr 16, 2013 at 12:11 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Tue, Apr 16, 2013 at 8:29 PM, Colin Cross <ccross@android.com> wrote:
>> Dropping __linux__ causes a make headers_check warning, which the
>> kbuild test robot reported this morning:
>> usr/include/linux/fuse.h:99: found __[us]{8,16,32,64} type without
>> #include <linux/types.h>
>> Using my patch without modification does not cause that warning.
>>
>> linux/types.h defines the types that are used to communicate between
>> the kernel and userspace.  Redefining those in each header makes no
>> sense, and will probably cause redefined types warnings if you compile
>> a userspace file that includes fuse.h and another uapi header that
>> properly includes linux/types.h.
>
> <linux/types.h> is linux specific while the fuse API is cross
> platform.  So the userspace header obviously has to use some cross
> platform type definitions.  Making the type definitions depend on
> __linux__ is probably just as unreliable in userspace as it is in the
> kernel, so why complicate things with that?

I'm not sure what you mean by __linux__ being unreliable, it is set by
any toolchain that is compield with linux as its target.  It should be
very reliable in userspace, its only unreliable in the kernel because
the kernel doesn't rely on any specific os target in the toolchain, it
is self contained.

With your change, compiling a program that includes linux/fuse.h and
linux/icmp.h against the headers installed by make headers_installed
results in some strange preprocessor results.  The lines in
int-ll64.h, which is what normally defines the userspace types, are:
typedef __signed__ char __s8;
typedef unsigned char __u8;

typedef __signed__ short __s16;
typedef unsigned short __u16;

typedef __signed__ int __s32;
typedef unsigned int __u32;

After preprocessing with your fuse.h included before icmp.h (which
includes linux/types.h, which eventually includes
asm-generic/int-ll64.h):
typedef __signed__ char __s8;
typedef unsigned char __u8;

typedef __signed__ short __s16;
typedef unsigned short uint16_t;

typedef __signed__ int int32_t;
typedef unsigned int uint32_t;

The first three lines are the kernel headers providing typedefs for
the types that are not used in fuse.h, and therefore not covered by
the #define hacks there.  The last three lines are a problem: now you
have redefined the stdint types to match the kernel's types, better
hope they match the host's stdint definitions or you'll get redefined
type warnings.

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 or when compiling the kernel.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] fuse: use kernel headers when __KERNEL__ is set
  2013-04-16 20:00               ` Colin Cross
@ 2013-04-17  9:57                 ` Miklos Szeredi
  2013-04-17 19:45                   ` Colin Cross
  0 siblings, 1 reply; 12+ messages in thread
From: Miklos Szeredi @ 2013-04-17  9:57 UTC (permalink / raw)
  To: Colin Cross
  Cc: Linus Torvalds, linux-kernel, fuse-devel, Arve Hjønnevåg

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@suse.cz>
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@android.com>
Reported-by: Colin Cross <ccross@android.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
---
 include/uapi/linux/fuse.h |  436 ++++++++++++++++++++++------------------------
 1 file changed, 216 insertions(+), 220 deletions(-)

--- a/include/uapi/linux/fuse.h
+++ b/include/uapi/linux/fuse.h
@@ -95,15 +95,10 @@
 #ifndef _LINUX_FUSE_H
 #define _LINUX_FUSE_H
 
-#ifdef __linux__
+#ifdef __KERNEL__
 #include <linux/types.h>
 #else
 #include <stdint.h>
-#define __u64 uint64_t
-#define __s64 int64_t
-#define __u32 uint32_t
-#define __s32 int32_t
-#define __u16 uint16_t
 #endif
 
 /*
@@ -139,42 +134,42 @@
    userspace works under 64bit kernels */
 
 struct fuse_attr {
-	__u64	ino;
-	__u64	size;
-	__u64	blocks;
-	__u64	atime;
-	__u64	mtime;
-	__u64	ctime;
-	__u32	atimensec;
-	__u32	mtimensec;
-	__u32	ctimensec;
-	__u32	mode;
-	__u32	nlink;
-	__u32	uid;
-	__u32	gid;
-	__u32	rdev;
-	__u32	blksize;
-	__u32	padding;
+	uint64_t	ino;
+	uint64_t	size;
+	uint64_t	blocks;
+	uint64_t	atime;
+	uint64_t	mtime;
+	uint64_t	ctime;
+	uint32_t	atimensec;
+	uint32_t	mtimensec;
+	uint32_t	ctimensec;
+	uint32_t	mode;
+	uint32_t	nlink;
+	uint32_t	uid;
+	uint32_t	gid;
+	uint32_t	rdev;
+	uint32_t	blksize;
+	uint32_t	padding;
 };
 
 struct fuse_kstatfs {
-	__u64	blocks;
-	__u64	bfree;
-	__u64	bavail;
-	__u64	files;
-	__u64	ffree;
-	__u32	bsize;
-	__u32	namelen;
-	__u32	frsize;
-	__u32	padding;
-	__u32	spare[6];
+	uint64_t	blocks;
+	uint64_t	bfree;
+	uint64_t	bavail;
+	uint64_t	files;
+	uint64_t	ffree;
+	uint32_t	bsize;
+	uint32_t	namelen;
+	uint32_t	frsize;
+	uint32_t	padding;
+	uint32_t	spare[6];
 };
 
 struct fuse_file_lock {
-	__u64	start;
-	__u64	end;
-	__u32	type;
-	__u32	pid; /* tgid */
+	uint64_t	start;
+	uint64_t	end;
+	uint32_t	type;
+	uint32_t	pid; /* tgid */
 };
 
 /**
@@ -364,143 +359,143 @@ enum fuse_notify_code {
 #define FUSE_COMPAT_ENTRY_OUT_SIZE 120
 
 struct fuse_entry_out {
-	__u64	nodeid;		/* Inode ID */
-	__u64	generation;	/* Inode generation: nodeid:gen must
-				   be unique for the fs's lifetime */
-	__u64	entry_valid;	/* Cache timeout for the name */
-	__u64	attr_valid;	/* Cache timeout for the attributes */
-	__u32	entry_valid_nsec;
-	__u32	attr_valid_nsec;
+	uint64_t	nodeid;		/* Inode ID */
+	uint64_t	generation;	/* Inode generation: nodeid:gen must
+					   be unique for the fs's lifetime */
+	uint64_t	entry_valid;	/* Cache timeout for the name */
+	uint64_t	attr_valid;	/* Cache timeout for the attributes */
+	uint32_t	entry_valid_nsec;
+	uint32_t	attr_valid_nsec;
 	struct fuse_attr attr;
 };
 
 struct fuse_forget_in {
-	__u64	nlookup;
+	uint64_t	nlookup;
 };
 
 struct fuse_forget_one {
-	__u64	nodeid;
-	__u64	nlookup;
+	uint64_t	nodeid;
+	uint64_t	nlookup;
 };
 
 struct fuse_batch_forget_in {
-	__u32	count;
-	__u32	dummy;
+	uint32_t	count;
+	uint32_t	dummy;
 };
 
 struct fuse_getattr_in {
-	__u32	getattr_flags;
-	__u32	dummy;
-	__u64	fh;
+	uint32_t	getattr_flags;
+	uint32_t	dummy;
+	uint64_t	fh;
 };
 
 #define FUSE_COMPAT_ATTR_OUT_SIZE 96
 
 struct fuse_attr_out {
-	__u64	attr_valid;	/* Cache timeout for the attributes */
-	__u32	attr_valid_nsec;
-	__u32	dummy;
+	uint64_t	attr_valid;	/* Cache timeout for the attributes */
+	uint32_t	attr_valid_nsec;
+	uint32_t	dummy;
 	struct fuse_attr attr;
 };
 
 #define FUSE_COMPAT_MKNOD_IN_SIZE 8
 
 struct fuse_mknod_in {
-	__u32	mode;
-	__u32	rdev;
-	__u32	umask;
-	__u32	padding;
+	uint32_t	mode;
+	uint32_t	rdev;
+	uint32_t	umask;
+	uint32_t	padding;
 };
 
 struct fuse_mkdir_in {
-	__u32	mode;
-	__u32	umask;
+	uint32_t	mode;
+	uint32_t	umask;
 };
 
 struct fuse_rename_in {
-	__u64	newdir;
+	uint64_t	newdir;
 };
 
 struct fuse_link_in {
-	__u64	oldnodeid;
+	uint64_t	oldnodeid;
 };
 
 struct fuse_setattr_in {
-	__u32	valid;
-	__u32	padding;
-	__u64	fh;
-	__u64	size;
-	__u64	lock_owner;
-	__u64	atime;
-	__u64	mtime;
-	__u64	unused2;
-	__u32	atimensec;
-	__u32	mtimensec;
-	__u32	unused3;
-	__u32	mode;
-	__u32	unused4;
-	__u32	uid;
-	__u32	gid;
-	__u32	unused5;
+	uint32_t	valid;
+	uint32_t	padding;
+	uint64_t	fh;
+	uint64_t	size;
+	uint64_t	lock_owner;
+	uint64_t	atime;
+	uint64_t	mtime;
+	uint64_t	unused2;
+	uint32_t	atimensec;
+	uint32_t	mtimensec;
+	uint32_t	unused3;
+	uint32_t	mode;
+	uint32_t	unused4;
+	uint32_t	uid;
+	uint32_t	gid;
+	uint32_t	unused5;
 };
 
 struct fuse_open_in {
-	__u32	flags;
-	__u32	unused;
+	uint32_t	flags;
+	uint32_t	unused;
 };
 
 struct fuse_create_in {
-	__u32	flags;
-	__u32	mode;
-	__u32	umask;
-	__u32	padding;
+	uint32_t	flags;
+	uint32_t	mode;
+	uint32_t	umask;
+	uint32_t	padding;
 };
 
 struct fuse_open_out {
-	__u64	fh;
-	__u32	open_flags;
-	__u32	padding;
+	uint64_t	fh;
+	uint32_t	open_flags;
+	uint32_t	padding;
 };
 
 struct fuse_release_in {
-	__u64	fh;
-	__u32	flags;
-	__u32	release_flags;
-	__u64	lock_owner;
+	uint64_t	fh;
+	uint32_t	flags;
+	uint32_t	release_flags;
+	uint64_t	lock_owner;
 };
 
 struct fuse_flush_in {
-	__u64	fh;
-	__u32	unused;
-	__u32	padding;
-	__u64	lock_owner;
+	uint64_t	fh;
+	uint32_t	unused;
+	uint32_t	padding;
+	uint64_t	lock_owner;
 };
 
 struct fuse_read_in {
-	__u64	fh;
-	__u64	offset;
-	__u32	size;
-	__u32	read_flags;
-	__u64	lock_owner;
-	__u32	flags;
-	__u32	padding;
+	uint64_t	fh;
+	uint64_t	offset;
+	uint32_t	size;
+	uint32_t	read_flags;
+	uint64_t	lock_owner;
+	uint32_t	flags;
+	uint32_t	padding;
 };
 
 #define FUSE_COMPAT_WRITE_IN_SIZE 24
 
 struct fuse_write_in {
-	__u64	fh;
-	__u64	offset;
-	__u32	size;
-	__u32	write_flags;
-	__u64	lock_owner;
-	__u32	flags;
-	__u32	padding;
+	uint64_t	fh;
+	uint64_t	offset;
+	uint32_t	size;
+	uint32_t	write_flags;
+	uint64_t	lock_owner;
+	uint32_t	flags;
+	uint32_t	padding;
 };
 
 struct fuse_write_out {
-	__u32	size;
-	__u32	padding;
+	uint32_t	size;
+	uint32_t	padding;
 };
 
 #define FUSE_COMPAT_STATFS_SIZE 48
@@ -510,32 +505,32 @@ struct fuse_statfs_out {
 };
 
 struct fuse_fsync_in {
-	__u64	fh;
-	__u32	fsync_flags;
-	__u32	padding;
+	uint64_t	fh;
+	uint32_t	fsync_flags;
+	uint32_t	padding;
 };
 
 struct fuse_setxattr_in {
-	__u32	size;
-	__u32	flags;
+	uint32_t	size;
+	uint32_t	flags;
 };
 
 struct fuse_getxattr_in {
-	__u32	size;
-	__u32	padding;
+	uint32_t	size;
+	uint32_t	padding;
 };
 
 struct fuse_getxattr_out {
-	__u32	size;
-	__u32	padding;
+	uint32_t	size;
+	uint32_t	padding;
 };
 
 struct fuse_lk_in {
-	__u64	fh;
-	__u64	owner;
+	uint64_t	fh;
+	uint64_t	owner;
 	struct fuse_file_lock lk;
-	__u32	lk_flags;
-	__u32	padding;
+	uint32_t	lk_flags;
+	uint32_t	padding;
 };
 
 struct fuse_lk_out {
@@ -543,134 +538,135 @@ struct fuse_lk_out {
 };
 
 struct fuse_access_in {
-	__u32	mask;
-	__u32	padding;
+	uint32_t	mask;
+	uint32_t	padding;
 };
 
 struct fuse_init_in {
-	__u32	major;
-	__u32	minor;
-	__u32	max_readahead;
-	__u32	flags;
+	uint32_t	major;
+	uint32_t	minor;
+	uint32_t	max_readahead;
+	uint32_t	flags;
 };
 
 struct fuse_init_out {
-	__u32	major;
-	__u32	minor;
-	__u32	max_readahead;
-	__u32	flags;
-	__u16   max_background;
-	__u16   congestion_threshold;
-	__u32	max_write;
+	uint32_t	major;
+	uint32_t	minor;
+	uint32_t	max_readahead;
+	uint32_t	flags;
+	uint16_t	max_background;
+	uint16_t	congestion_threshold;
+	uint32_t	max_write;
 };
 
 #define CUSE_INIT_INFO_MAX 4096
 
 struct cuse_init_in {
-	__u32	major;
-	__u32	minor;
-	__u32	unused;
-	__u32	flags;
+	uint32_t	major;
+	uint32_t	minor;
+	uint32_t	unused;
+	uint32_t	flags;
 };
 
 struct cuse_init_out {
-	__u32	major;
-	__u32	minor;
-	__u32	unused;
-	__u32	flags;
-	__u32	max_read;
-	__u32	max_write;
-	__u32	dev_major;		/* chardev major */
-	__u32	dev_minor;		/* chardev minor */
-	__u32	spare[10];
+	uint32_t	major;
+	uint32_t	minor;
+	uint32_t	unused;
+	uint32_t	flags;
+	uint32_t	max_read;
+	uint32_t	max_write;
+	uint32_t	dev_major;		/* chardev major */
+	uint32_t	dev_minor;		/* chardev minor */
+	uint32_t	spare[10];
 };
 
 struct fuse_interrupt_in {
-	__u64	unique;
+	uint64_t	unique;
 };
 
 struct fuse_bmap_in {
-	__u64	block;
-	__u32	blocksize;
-	__u32	padding;
+	uint64_t	block;
+	uint32_t	blocksize;
+	uint32_t	padding;
 };
 
 struct fuse_bmap_out {
-	__u64	block;
+	uint64_t	block;
 };
 
 struct fuse_ioctl_in {
-	__u64	fh;
-	__u32	flags;
-	__u32	cmd;
-	__u64	arg;
-	__u32	in_size;
-	__u32	out_size;
+	uint64_t	fh;
+	uint32_t	flags;
+	uint32_t	cmd;
+	uint64_t	arg;
+	uint32_t	in_size;
+	uint32_t	out_size;
 };
 
 struct fuse_ioctl_iovec {
-	__u64	base;
-	__u64	len;
+	uint64_t	base;
+	uint64_t	len;
 };
 
 struct fuse_ioctl_out {
-	__s32	result;
-	__u32	flags;
-	__u32	in_iovs;
-	__u32	out_iovs;
+	int32_t		result;
+	uint32_t	flags;
+	uint32_t	in_iovs;
+	uint32_t	out_iovs;
 };
 
 struct fuse_poll_in {
-	__u64	fh;
-	__u64	kh;
-	__u32	flags;
-	__u32   events;
+	uint64_t	fh;
+	uint64_t	kh;
+	uint32_t	flags;
+	uint32_t	events;
 };
 
 struct fuse_poll_out {
-	__u32	revents;
-	__u32	padding;
+	uint32_t	revents;
+	uint32_t	padding;
 };
 
 struct fuse_notify_poll_wakeup_out {
-	__u64	kh;
+	uint64_t	kh;
 };
 
 struct fuse_fallocate_in {
-	__u64	fh;
-	__u64	offset;
-	__u64	length;
-	__u32	mode;
-	__u32	padding;
+	uint64_t	fh;
+	uint64_t	offset;
+	uint64_t	length;
+	uint32_t	mode;
+	uint32_t	padding;
 };
 
 struct fuse_in_header {
-	__u32	len;
-	__u32	opcode;
-	__u64	unique;
-	__u64	nodeid;
-	__u32	uid;
-	__u32	gid;
-	__u32	pid;
-	__u32	padding;
+	uint32_t	len;
+	uint32_t	opcode;
+	uint64_t	unique;
+	uint64_t	nodeid;
+	uint32_t	uid;
+	uint32_t	gid;
+	uint32_t	pid;
+	uint32_t	padding;
 };
 
 struct fuse_out_header {
-	__u32	len;
-	__s32	error;
-	__u64	unique;
+	uint32_t	len;
+	int32_t		error;
+	uint64_t	unique;
 };
 
 struct fuse_dirent {
-	__u64	ino;
-	__u64	off;
-	__u32	namelen;
-	__u32	type;
+	uint64_t	ino;
+	uint64_t	off;
+	uint32_t	namelen;
+	uint32_t	type;
 	char name[];
 };
 
 #define FUSE_NAME_OFFSET offsetof(struct fuse_dirent, name)
-#define FUSE_DIRENT_ALIGN(x) (((x) + sizeof(__u64) - 1) & ~(sizeof(__u64) - 1))
+#define FUSE_DIRENT_ALIGN(x) \
+	(((x) + sizeof(uint64_t) - 1) & ~(sizeof(uint64_t) - 1))
 #define FUSE_DIRENT_SIZE(d) \
 	FUSE_DIRENT_ALIGN(FUSE_NAME_OFFSET + (d)->namelen)
 
@@ -685,47 +681,47 @@ struct fuse_direntplus {
 	FUSE_DIRENT_ALIGN(FUSE_NAME_OFFSET_DIRENTPLUS + (d)->dirent.namelen)
 
 struct fuse_notify_inval_inode_out {
-	__u64	ino;
-	__s64	off;
-	__s64	len;
+	uint64_t	ino;
+	int64_t		off;
+	int64_t		len;
 };
 
 struct fuse_notify_inval_entry_out {
-	__u64	parent;
-	__u32	namelen;
-	__u32	padding;
+	uint64_t	parent;
+	uint32_t	namelen;
+	uint32_t	padding;
 };
 
 struct fuse_notify_delete_out {
-	__u64	parent;
-	__u64	child;
-	__u32	namelen;
-	__u32	padding;
+	uint64_t	parent;
+	uint64_t	child;
+	uint32_t	namelen;
+	uint32_t	padding;
 };
 
 struct fuse_notify_store_out {
-	__u64	nodeid;
-	__u64	offset;
-	__u32	size;
-	__u32	padding;
+	uint64_t	nodeid;
+	uint64_t	offset;
+	uint32_t	size;
+	uint32_t	padding;
 };
 
 struct fuse_notify_retrieve_out {
-	__u64	notify_unique;
-	__u64	nodeid;
-	__u64	offset;
-	__u32	size;
-	__u32	padding;
+	uint64_t	notify_unique;
+	uint64_t	nodeid;
+	uint64_t	offset;
+	uint32_t	size;
+	uint32_t	padding;
 };
 
 /* Matches the size of fuse_write_in */
 struct fuse_notify_retrieve_in {
-	__u64	dummy1;
-	__u64	offset;
-	__u32	size;
-	__u32	dummy2;
-	__u64	dummy3;
-	__u64	dummy4;
+	uint64_t	dummy1;
+	uint64_t	offset;
+	uint32_t	size;
+	uint32_t	dummy2;
+	uint64_t	dummy3;
+	uint64_t	dummy4;
 };
 
 #endif /* _LINUX_FUSE_H */

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] fuse: use kernel headers when __KERNEL__ is set
  2013-04-17  9:57                 ` Miklos Szeredi
@ 2013-04-17 19:45                   ` Colin Cross
  2013-04-17 20:59                     ` Miklos Szeredi
  0 siblings, 1 reply; 12+ messages in thread
From: Colin Cross @ 2013-04-17 19:45 UTC (permalink / raw)
  To: Miklos Szeredi
  Cc: Linus Torvalds, lkml, open list:FUSE: FILESYSTEM...,
	Arve Hjønnevåg

On Wed, Apr 17, 2013 at 2:57 AM, Miklos Szeredi <miklos@szeredi.hu> 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@suse.cz>
> 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@android.com>
> Reported-by: Colin Cross <ccross@android.com>
> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>

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@android.com>

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.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] fuse: use kernel headers when __KERNEL__ is set
  2013-04-17 19:45                   ` Colin Cross
@ 2013-04-17 20:59                     ` Miklos Szeredi
  0 siblings, 0 replies; 12+ messages in thread
From: Miklos Szeredi @ 2013-04-17 20:59 UTC (permalink / raw)
  To: Colin Cross; +Cc: Linus Torvalds, lkml, fuse-devel, Arve Hjønnevåg

On Wed, Apr 17, 2013 at 9:45 PM, Colin Cross <ccross@android.com> wrote:
> 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@android.com>

Thanks for testing.

Linus,  can you please pull this single fix from:

git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git for-linus

Thanks,
Miklos
----

Miklos Szeredi (1):
      fuse: fix type definitions in uapi header

---
 include/uapi/linux/fuse.h |  436 ++++++++++++++++++++++-----------------------
 1 file changed, 216 insertions(+), 220 deletions(-)

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2013-04-17 20:59 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-15 20:41 [PATCH] fuse: use kernel headers when __KERNEL__ is set Colin Cross
2013-04-15 21:47 ` Colin Cross
2013-04-16 14:21   ` Miklos Szeredi
2013-04-16 15:59     ` Linus Torvalds
2013-04-16 17:24       ` Miklos Szeredi
2013-04-16 18:21         ` Linus Torvalds
2013-04-16 18:29           ` Colin Cross
2013-04-16 19:11             ` Miklos Szeredi
2013-04-16 20:00               ` Colin Cross
2013-04-17  9:57                 ` Miklos Szeredi
2013-04-17 19:45                   ` Colin Cross
2013-04-17 20:59                     ` Miklos Szeredi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).