pm24.git/include/linux/types.h, branch v3.2-rc3

rcu: Move rcu_head definition to types.h

2011-09-29T04:36:38Z

Take a first step towards untangling Linux kernel header files by placing the struct rcu_head definition into include/linux/types.h and including include/linux/types.h in include/linux/rcupdate.h where struct rcu_head used to be defined. The actual inclusion point for include/linux/types.h is with the rest of the #include directives rather than at the point where struct rcu_head used to be defined, as suggested by Mathieu Desnoyers. Once this is in place, then header files that need only rcu_head can include types.h rather than rcupdate.h. Signed-off-by: Paul E. McKenney Cc: Paul Gortmaker Acked-by: Mathieu Desnoyers

add the common dma_addr_t typedef to include/linux/types.h

2011-03-23T00:44:09Z

All architectures can use the common dma_addr_t typedef now. We can remove the arch specific dma_addr_t. Signed-off-by: FUJITA Tomonori Acked-by: Arnd Bergmann Cc: Ingo Molnar Cc: Thomas Gleixner Cc: "H. Peter Anvin" Cc: Ivan Kokshaysky Cc: Richard Henderson Cc: Matt Turner Cc: "Luck, Tony" Cc: Ralf Baechle Cc: Benjamin Herrenschmidt Cc: Heiko Carstens Cc: Martin Schwidefsky Cc: Chris Metcalf Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

types.h: move misplaced comment

2010-10-26T23:52:03Z

This comment landed in the wrong place. Cc: Andi Kleen Cc: Arnd Bergmann Cc: David Miller Cc: Eric Paris Cc: Jan Engelhardt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

types.h: define __aligned_u64 and expose to userspace

2010-10-15T21:42:24Z

We currently have a kernel internal type called aligned_u64 which aligns __u64's on 8 bytes boundaries even on systems which would normally align them on 4 byte boundaries. This patch creates a new type __aligned_u64 which does the same thing but which is exposed to userspace rather than being kernel internal. [akpm: merge early as both the net and audit trees want this] [akpm@linux-foundation.org: enhance the comment describing the reasons for using aligned_u64. Via Andreas and Andi.] Based-on-patch-by: Andreas Gruenbacher Signed-off-by: Eric Paris Cc: Jan Engelhardt Cc: David Miller Cc: Andi Kleen Cc: Arnd Bergmann Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Merge branch 'master' into for-linus

2010-08-06T14:37:02Z

fix #warning about using kernel headers in userpsace

2010-07-11T19:38:56Z

Move the preprocessor #warning message: warning: #warning Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders from kernel.h to types.h. And also fixe the #warning message due to the preprocessor not being able to read the web address due to it thinking it was the start of a comment. also remove the extra #ifndef _KERNEL_ since it's already there. Signed-off-by: Justin P. Mattock Cc: Arnd Bergmann Signed-off-by: Jiri Kosina

Move list types from to .

2010-07-06T17:33:54Z

This allows a list_head (or hlist_head, etc.) to be used from places that used to be impractical, in particular , which used to cause include file recursion: includes , which always includes for the prefetch macros, as well as , which often includes directly or indirectly. This avoids a lot of painful workaround hackery on the tile architecture, where we use a list_head in the thread_struct to chain together tasks that are activated on a particular hardwall. Signed-off-by: Chris Metcalf Reviewed-by: Matthew Wilcox

atomic_t: Remove volatile from atomic_t definition

2010-05-17T14:57:27Z

When looking at a performance problem on PowerPC, I noticed some awful code generation: c00000000051fc98: 3b 60 00 01 li r27,1 ... c00000000051fca0: 3b 80 00 00 li r28,0 ... c00000000051fcdc: 93 61 00 70 stw r27,112(r1) c00000000051fce0: 93 81 00 74 stw r28,116(r1) c00000000051fce4: 81 21 00 70 lwz r9,112(r1) c00000000051fce8: 80 01 00 74 lwz r0,116(r1) c00000000051fcec: 7d 29 07 b4 extsw r9,r9 c00000000051fcf0: 7c 00 07 b4 extsw r0,r0 c00000000051fcf4: 7c 20 04 ac lwsync c00000000051fcf8: 7d 60 f8 28 lwarx r11,0,r31 c00000000051fcfc: 7c 0b 48 00 cmpw r11,r9 c00000000051fd00: 40 c2 00 10 bne- c00000000051fd10 c00000000051fd04: 7c 00 f9 2d stwcx. r0,0,r31 c00000000051fd08: 40 c2 ff f0 bne+ c00000000051fcf8 c00000000051fd0c: 4c 00 01 2c isync We create two constants, write them out to the stack, read them straight back in and sign extend them. What a mess. It turns out this bad code is a result of us defining atomic_t as a volatile int. We removed the volatile attribute from the powerpc atomic_t definition years ago, but commit ea435467500612636f8f4fb639ff6e76b2496e4b (atomic_t: unify all arch definitions) added it back in. To dig up an old quote from Linus: > The fact is, volatile on data structures is a bug. It's a wart in the C > language. It shouldn't be used. > > Volatile accesses in *code* can be ok, and if we have "atomic_read()" > expand to a "*(volatile int *)&(x)->value", then I'd be ok with that. > > But marking data structures volatile just makes the compiler screw up > totally, and makes code for initialization sequences etc much worse. And screw up it does :) With the volatile removed, we see much more reasonable code generation: c00000000051f5b8: 3b 60 00 01 li r27,1 ... c00000000051f5c0: 3b 80 00 00 li r28,0 ... c00000000051fc7c: 7c 20 04 ac lwsync c00000000051fc80: 7c 00 f8 28 lwarx r0,0,r31 c00000000051fc84: 7c 00 d8 00 cmpw r0,r27 c00000000051fc88: 40 c2 00 10 bne- c00000000051fc98 c00000000051fc8c: 7f 80 f9 2d stwcx. r28,0,r31 c00000000051fc90: 40 c2 ff f0 bne+ c00000000051fc80 c00000000051fc94: 4c 00 01 2c isync Six instructions less. Signed-off-by: Anton Blanchard Signed-off-by: Linus Torvalds

block: rename CONFIG_LBD to CONFIG_LBDAF

2009-06-19T06:08:50Z

Follow-up to "block: enable by default support for large devices and files on 32-bit archs". Rename CONFIG_LBD to CONFIG_LBDAF to: - allow update of existing [def]configs for "default y" change - reflect that it is used also for large files support nowadays Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Jens Axboe

remove __KERNEL_STRICT_NAMES

2009-03-26T17:14:21Z

With the last used of non-strict names gone from the exported header files, we can remove the old libc5 compatibility cruft from our headers and only export strict types. Signed-off-by: Arnd Bergmann Signed-off-by: H. Peter Anvin Signed-off-by: Ingo Molnar