Home » Mailing list archives » linux-kernel » 2008 » April » 29

Re: [2.6 patch] reiserfs: some functions mustn't be inline

Previous thread: [git pull] x86 fixes by Ingo Molnar on Thursday, April 24, 2008 - 5:37 pm. (1 message)

Next thread: [PATCH] Minimal mmu notifiers for kvm by Rusty Russell on Thursday, April 24, 2008 - 6:13 pm. (3 messages)
[view original message]
From: Ingo Molnar <mingo@...>
To: Linus Torvalds <torvalds@...>
Cc: <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>
Subject: [git pull] generic bitops
Date: Thursday, April 24, 2008 - 5:57 pm

Linus, please pull the generic bitops tree from:


   git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-generic-bitops.git for-linus


this started out as improvements/generalizations to x86 bitops, but grew

generic impact (and generic optimizations) as well, so it's offered as a

separate tree.


Thanks,


	Ingo


------------------>

Alexander van Heukelum (12):

      x86: change x86 to use generic find_next_bit

      x86, uml: fix uml with generic find_next_bit for x86

      x86, generic: optimize find_next_(zero_)bit for small constant-size bitmaps

      x86: merge the simple bitops and move them to bitops.h

      generic: introduce a generic __fls implementation

      generic: implement __fls on all 64-bit archs

      bitops: use __fls for fls64 on 64-bit archs

      x86: generic versions of find_first_(zero_)bit, convert i386

      x86: switch 64-bit to generic find_first_bit

      x86: optimize find_first_bit for small bitmaps

      x86, UML: remove x86-specific implementations of find_first_bit

      x86: finalize bitops unification


Joe Perches (1):

      x86: include/asm-x86/pgalloc.h/bitops.h: checkpatch cleanups - formatting only


 arch/um/Kconfig.i386               |    8 ++

 arch/um/Kconfig.x86_64             |    8 ++

 arch/um/sys-i386/Makefile          |    2 +-

 arch/um/sys-x86_64/Makefile        |    2 +-

 arch/x86/Kconfig                   |    6 ++

 arch/x86/Kconfig.cpu               |    2 +-

 arch/x86/lib/Makefile              |    3 +-

 arch/x86/lib/bitops_32.c           |   70 --------------

 arch/x86/lib/bitops_64.c           |  175 ------------------------------------

 include/asm-alpha/bitops.h         |    5 +

 include/asm-generic/bitops/__fls.h |   43 +++++++++

 include/asm-generic/bitops/find.h  |    2 +

 include/asm-generic/bitops/fls64.h |   22 +++++

 include/asm-ia64/bitops.h          |   16 ++++

 include/asm-mips/bitops.h          |    5 +

 include/asm-parisc/bitops.h        |    1 +

 include/asm-powerpc/bitops.h       |    ...
[ message continues ]
[view original message]
From: Linus Torvalds <torvalds@...>
To: Ingo Molnar <mingo@...>
Cc: <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>
Subject: Re: [git pull] generic bitops
Date: Thursday, April 24, 2008 - 6:14 pm

.. because instead of having each architecture do these kinds of things,

we're trying to make the *generic* code (ie lib/Kconfig) do


	config GENERIC_FIND_FIRST_BIT

		bool

		default n


so that you only have one single declaration (close to where the code

actually exists), and then the architectures would just do


	select GENERIC_FIND_FIRST_BIT

	select GENERIC_FIND_NEXT_BIT


in their architecture settings. That's how we're now doing things like

HAVE_IDE, HAVE_OPROFILE, etc etc.


Hmm?


		Linus

--
[view original message]
From: Ingo Molnar <mingo@...>
To: Linus Torvalds <torvalds@...>
Cc: <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>
Subject: [git pull] generic bitops, take 2
Date: Saturday, April 26, 2008 - 11:15 am

i've added Alexander's patch that does the cleanup suggested by you, you

can pull the updated tree from:


   git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-generic-bitops-v2.git for-linus


Thanks,


	Ingo


------------------>

Alexander van Heukelum (13):

      x86: change x86 to use generic find_next_bit

      x86, uml: fix uml with generic find_next_bit for x86

      x86, generic: optimize find_next_(zero_)bit for small constant-size bitmaps

      x86: merge the simple bitops and move them to bitops.h

      generic: introduce a generic __fls implementation

      generic: implement __fls on all 64-bit archs

      bitops: use __fls for fls64 on 64-bit archs

      x86: generic versions of find_first_(zero_)bit, convert i386

      x86: switch 64-bit to generic find_first_bit

      x86: optimize find_first_bit for small bitmaps

      x86, UML: remove x86-specific implementations of find_first_bit

      x86: finalize bitops unification

      x86, bitops: select the generic bitmap search functions


Joe Perches (1):

      x86: include/asm-x86/pgalloc.h/bitops.h: checkpatch cleanups - formatting only


 arch/um/Kconfig.x86_64             |    8 ++

 arch/um/sys-i386/Makefile          |    2 +-

 arch/um/sys-x86_64/Makefile        |    2 +-

 arch/x86/Kconfig.cpu               |    7 ++-

 arch/x86/lib/Makefile              |    3 +-

 arch/x86/lib/bitops_32.c           |   70 --------------

 arch/x86/lib/bitops_64.c           |  175 ------------------------------------

 include/asm-alpha/bitops.h         |    5 +

 include/asm-generic/bitops/__fls.h |   43 +++++++++

 include/asm-generic/bitops/find.h  |    2 +

 include/asm-generic/bitops/fls64.h |   22 +++++

 include/asm-ia64/bitops.h          |   16 ++++

 include/asm-mips/bitops.h          |    5 +

 include/asm-parisc/bitops.h        |    1 +

 include/asm-powerpc/bitops.h       |    5 +

 include/asm-s390/bitops.h          |    1 +

 include/asm-sh/bitops.h            |    1 +

 include/asm-sparc64/bitops.h       | ...
[ message continues ]
[view original message]
From: Linus Torvalds <torvalds@...>
To: Ingo Molnar <mingo@...>
Cc: Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>
Subject: Re: [git pull] generic bitops, take 2
Date: Saturday, April 26, 2008 - 1:03 pm

It still declares this GENERIC_FIND_*_BIT thing separately for UM.


Yes, that may _work_, but it's wrong to define it in two different places. 


It also makes me wonder why Kconfig.i386 can just include

arch/x86/Kconfig.cpu, but x86_64 cannot?


		Linus

--
[view original message]
From: Sam Ravnborg <sam@...>
To: Linus Torvalds <torvalds@...>
Cc: Ingo Molnar <mingo@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>
Subject: Re: [git pull] generic bitops, take 2
Date: Saturday, April 26, 2008 - 1:34 pm

It would be nice if this could follow the sample outlined

in Documentation/kbuild/kconfig-language.txt.


See the section about HAVE_


Basically we should only define the config symbol once in all

the Kconfig files and where we then want to use this function

we should select the config symbol.


	Sam

--
[view original message]
From: Ingo Molnar <mingo@...>
To: Linus Torvalds <torvalds@...>
Cc: Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: Re: [git pull] generic bitops, take 2
Date: Saturday, April 26, 2008 - 1:22 pm

hm, indeed arch/um/Kconfig.i386 is assymetric to Kconfig.x86_64. Jeff

Cc:-ed.


trying to see whether changing that would still result in a working UML

arch i found that current UML doesnt seem to build here:


 arch/um/os-Linux/helper.c: In function 'run_helper':

 arch/um/os-Linux/helper.c:73: error: 'PATH_MAX' undeclared (first use in this function)


it needs the patch below.


then it fails with:


 mm/filemap.c: In function '__generic_file_aio_write_nolock':

 mm/filemap.c:1831: sorry, unimplemented: inlining failed in call to 'generic_write_checks': function body not available


i used:


   make ARCH=um SUBARCH=x86_64 -j64 linux


on x86-64, gcc-4.3.0-0.13. Config is:


   http://redhat.com/~mingo/misc/.config.um


i also tried gcc 4.2.3, that built it fine but didnt link it:


/opt/crosstool/gcc-4.2.3-glibc-2.3.6/x86_64-unknown-linux-gnu/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/../../../../x86_64-unknown-linux-gnu/bin/ld:

warning: ld-linux-x86-64.so.2, needed by

/opt/crosstool/gcc-4.2.3-glibc-2.3.6/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sys-root/lib/../lib64/libc.so.6,

not found (try using -rpath or -rpath-link)

/opt/crosstool/gcc-4.2.3-glibc-2.3.6/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sys-root/lib/../lib64/libc.so.6:

undefined reference to `_dl_argv@GLIBC_PRIVATE'


...

/opt/crosstool/gcc-4.2.3-glibc-2.3.6/x86_64-unknown-linux-gnu/lib/gcc/x86_64-unknown-linux-gnu/4.2.3/../../../../x86_64-unknown-linux-gnu/bin/ld:

warning: .fini_array section has zero size collect2: ld returned 1 exit

status

distcc[29125] ERROR: compile (null) on localhost failed

  KSYM    .tmp_kallsyms1.S

/opt/crosstool/gcc-4.2.3-glibc-2.3.6/x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu-nm:

'.tmp_vmlinux1': No such file


perhaps the combination of distcc and crosscompilers doesnt work well on

UML? (it works fine with other architectures)


	Ingo


--------------->

Subject: uml: fix

From: Ingo Molnar <mingo@elte.hu>

Date: Sat Apr 26 18:59:42 CEST 2008

...
[ message continues ]
[view original message]
From: Jeff Dike <jdike@...>
To: Ingo Molnar <mingo@...>
Cc: Linus Torvalds <torvalds@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>
Subject: Re: [git pull] generic bitops, take 2
Date: Monday, April 28, 2008 - 1:26 pm

Looks like Adrian just hit that too.  As Linus pointed out,

__generic_file_aio_write_nolock calls generic_write_checks at line

2383, and that's available at line 1831, which the error message

helpfully points out.  I don't see how gcc can be claiming that the

function body isn't available when it's telling you exactly where it

is.


				Jeff


--

Work email - jdike at linux dot intel dot com

--
[view original message]
From: Adrian Bunk <bunk@...>
To: <jack@...>
Cc: Linus Torvalds <torvalds@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>, Ingo Molnar <mingo@...>
Subject: [2.6 patch] fs/udf/partition.c:udf_get_pblock() mustn't be inline
Date: Monday, April 28, 2008 - 11:38 am

This patch fixes the following build error with UML and gcc 4.3:


<--  snip  -->


...

  CC      fs/udf/partition.o

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf/partition.c: In function ‘udf_get_pblock_virt15’:

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf/partition.c:32: sorry, unimplemented: inlining failed in call to ‘udf_get_pblock’: function body not available

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf/partition.c:102: sorry, unimplemented: called from here

make[3]: *** [fs/udf/partition.o] Error 1


<--  snip  -->


Signed-off-by: Adrian Bunk <bunk@kernel.org>


---

9739b5f94fdf781f71cbb4c7b2f8f6d9e3d58e55 diff --git a/fs/udf/partition.c b/fs/udf/partition.c

index 63610f0..96dfd20 100644

--- a/fs/udf/partition.c

+++ b/fs/udf/partition.c

@@ -27,8 +27,8 @@

 #include <linux/slab.h>

 #include <linux/buffer_head.h>


-inline uint32_t udf_get_pblock(struct super_block *sb, uint32_t block,

-			       uint16_t partition, uint32_t offset)

+uint32_t udf_get_pblock(struct super_block *sb, uint32_t block,

+			uint16_t partition, uint32_t offset)

 {

 	struct udf_sb_info *sbi = UDF_SB(sb);

 	struct udf_part_map *map;


--
[view original message]
From: Jan Kara <jack@...>
To: Adrian Bunk <bunk@...>
Cc: Linus Torvalds <torvalds@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>, Ingo Molnar <mingo@...>
Subject: Re: [2.6 patch] fs/udf/partition.c:udf_get_pblock() mustn't be inline
Date: Monday, April 28, 2008 - 12:47 pm

Thanks. Merged into UDF git tree.


--

Jan Kara <jack@suse.cz>

SUSE Labs, CR

--
[view original message]
From: Adrian Bunk <bunk@...>
To: <reiserfs-devel@...>
Cc: Linus Torvalds <torvalds@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>, Ingo Molnar <mingo@...>
Subject: [2.6 patch] reiserfs: some functions mustn't be inline
Date: Monday, April 28, 2008 - 11:38 am

This patch fixes the following build errors with UML and gcc 4.3:


<--  snip  -->


...

  CC      fs/reiserfs/do_balan.o

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/do_balan.c: In function ‘balance_leaf’:

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/do_balan.c:34: sorry, unimplemented: inlining failed in call to ‘do_balance_mark_leaf_dirty’: function body not available

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/do_balan.c:1018: sorry, unimplemented: called from here

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/do_balan.c:34: sorry, unimplemented: inlining failed in call to ‘do_balance_mark_leaf_dirty’: function body not available

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/do_balan.c:1174: sorry, unimplemented: called from here

make[3]: *** [fs/reiserfs/do_balan.o] Error 1

...

  CC      fs/reiserfs/namei.o

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/namei.c: In function ‘search_by_entry_key’:

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/namei.c:66: sorry, unimplemented: inlining failed in call to ‘set_de_name_and_namelen’: function body not available

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/namei.c:162: sorry, unimplemented: called from here

make[3]: *** [fs/reiserfs/namei.o] Error 1

...

  CC      fs/reiserfs/inode.o

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/inode.c: In function ‘reiserfs_get_block’:

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/inode.c:108: sorry, unimplemented: inlining failed in call to ‘make_le_item_head’: function body not available

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/inode.c:776: sorry, unimplemented: called from here

make[3]: *** [fs/reiserfs/inode.o] Error 1

...

  CC      fs/reiserfs/stree.o

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/stree.c: In function ‘comp_keys’:

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/reiserfs/stree.c:86: sorry, unimplemented: inlining failed in call to ‘comp_short_keys...
[ message continues ]
[view original message]
From: Edward Shishkin <edward.shishkin@...>
To: Adrian Bunk <bunk@...>
Cc: <reiserfs-devel@...>, Linus Torvalds <torvalds@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, <heukelum@...>, <jdike@...>, <mingo@...>
Subject: Re: [2.6 patch] reiserfs: some functions mustn't be inline
Date: Tuesday, April 29, 2008 - 6:43 pm

Hello.

I would make some of them static inline (my version is appended).


Thanks,

Edward.


Make the following functions static inline:


. do_balance_mark_leaf_dirty

. set_de_name_and_namelen

. comp_short_keys

. B_IS_IN_TREE

. copy_item_head

. le_key2cpu_key

. decrement_bcount


Signed-off-by: Edward Shishkin <edward.shishkin@gmail.com>


---

 linux-2.6.25-mm1/fs/reiserfs/do_balan.c      |   10 --

 linux-2.6.25-mm1/fs/reiserfs/inode.c         |    8 +-

 linux-2.6.25-mm1/fs/reiserfs/namei.c         |   12 ---

 linux-2.6.25-mm1/fs/reiserfs/stree.c         |   77 ---------------------

 linux-2.6.25-mm1/include/linux/reiserfs_fs.h |   99 +++++++++++++++++++++++----

 5 files changed, 93 insertions(+), 113 deletions(-)


--- linux-2.6.25-mm1/fs/reiserfs/do_balan.c.orig

+++ linux-2.6.25-mm1/fs/reiserfs/do_balan.c

@@ -29,16 +29,6 @@

 					   is interrupting do_balance */

 #endif


-inline void do_balance_mark_leaf_dirty(struct tree_balance *tb,

-				       struct buffer_head *bh, int flag)

-{

-	journal_mark_dirty(tb->transaction_handle,

-			   tb->transaction_handle->t_super, bh);

-}

-

-#define do_balance_mark_internal_dirty do_balance_mark_leaf_dirty

-#define do_balance_mark_sb_dirty do_balance_mark_leaf_dirty

-

 /* summary:

  if deleting something ( tb->insert_size[0] < 0 )

    return(balance_leaf_when_delete()); (flag d handled here)

--- linux-2.6.25-mm1/fs/reiserfs/inode.c.orig

+++ linux-2.6.25-mm1/fs/reiserfs/inode.c

@@ -101,10 +101,10 @@

 //

 // when key is 0, do not set version and short key

 //

-inline void make_le_item_head(struct item_head *ih, const struct cpu_key *key,

-			      int version,

-			      loff_t offset, int type, int length,

-			      int entry_count /*or ih_free_space */ )

+void make_le_item_head(struct item_head *ih, const struct cpu_key *key,

+		       int version,

+		       loff_t offset, int type, int length,

+		       int entry_count /*or ih_free_space */ )

 {

 	if (key) {

 		ih->ih_key.k_dir_id = cpu_to_le3...
[ message continues ]
[view original message]
From: Adrian Bunk <bunk@...>
To: <davem@...>
Cc: Linus Torvalds <torvalds@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>, Ingo Molnar <mingo@...>, <netdev@...>
Subject: [2.6 patch] net/ipv4/ip_output.c:ip_send_check() mustn't be inline
Date: Monday, April 28, 2008 - 11:38 am

This patch fixes the following build error with UML and gcc 4.3:


<--  snip  -->


...

  CC      net/ipv4/ip_output.o

/home/bunk/linux/kernel-2.6/git/linux-2.6/net/ipv4/ip_output.c: In function ‘__ip_local_out’:

/home/bunk/linux/kernel-2.6/git/linux-2.6/net/ipv4/ip_output.c:89: sorry, unimplemented: inlining failed in call to ‘ip_send_check’: function body not available

/home/bunk/linux/kernel-2.6/git/linux-2.6/net/ipv4/ip_output.c:99: sorry, unimplemented: called from here

make[3]: *** [net/ipv4/ip_output.o] Error 1


<--  snip  -->


Signed-off-by: Adrian Bunk <bunk@kernel.org>


---

936e490777359bfde622148ff5af1e19d8c248b5 diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c

index 0834926..985a719 100644

--- a/net/ipv4/ip_output.c

+++ b/net/ipv4/ip_output.c

@@ -85,7 +85,7 @@

 int sysctl_ip_default_ttl __read_mostly = IPDEFTTL;


 /* Generate a checksum for an outgoing IP datagram. */

-__inline__ void ip_send_check(struct iphdr *iph)

+void ip_send_check(struct iphdr *iph)

 {

 	iph->check = 0;

 	iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl);


--
[view original message]
From: Adrian Bunk <bunk@...>
To: <axboe@...>
Cc: Linus Torvalds <torvalds@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>, Ingo Molnar <mingo@...>
Subject: [2.6 patch] block/blk-barrier.c:blk_ordered_cur_seq() mustn't be inline
Date: Monday, April 28, 2008 - 11:38 am

This patch fixes the following build error with UML and gcc 4.3:


<--  snip  -->


...

  CC      block/blk-barrier.o

/home/bunk/linux/kernel-2.6/git/linux-2.6/block/blk-barrier.c: In function ‘blk_do_ordered’:

/home/bunk/linux/kernel-2.6/git/linux-2.6/block/blk-barrier.c:57: sorry, unimplemented: inlining failed in call to ‘blk_ordered_cur_seq’: function body not available

/home/bunk/linux/kernel-2.6/git/linux-2.6/block/blk-barrier.c:252: sorry, unimplemented: called from here

/home/bunk/linux/kernel-2.6/git/linux-2.6/block/blk-barrier.c:57: sorry, unimplemented: inlining failed in call to ‘blk_ordered_cur_seq’: function body not available

/home/bunk/linux/kernel-2.6/git/linux-2.6/block/blk-barrier.c:253: sorry, unimplemented: called from here

make[2]: *** [block/blk-barrier.o] Error 1


<--  snip  -->


Signed-off-by: Adrian Bunk <bunk@kernel.org>


---

e322a237766808e2c198f4521a9c8ba1fae6b77c diff --git a/block/blk-barrier.c b/block/blk-barrier.c

index 55c5f1f..2b9f2e9 100644

--- a/block/blk-barrier.c

+++ b/block/blk-barrier.c

@@ -53,7 +53,7 @@ EXPORT_SYMBOL(blk_queue_ordered);

 /*

  * Cache flushing for ordered writes handling

  */

-inline unsigned blk_ordered_cur_seq(struct request_queue *q)

+unsigned blk_ordered_cur_seq(struct request_queue *q)

 {

 	if (!q->ordseq)

 		return 0;


--
[view original message]
From: Jens Axboe <jens.axboe@...>
To: Adrian Bunk <bunk@...>
Cc: Linus Torvalds <torvalds@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>, Ingo Molnar <mingo@...>
Subject: Re: [2.6 patch] block/blk-barrier.c:blk_ordered_cur_seq() mustn't be inline
Date: Tuesday, April 29, 2008 - 3:46 am

Applied


--

Jens Axboe


--
[view original message]
From: Adrian Bunk <bunk@...>
To: Ingo Molnar <mingo@...>
Cc: Linus Torvalds <torvalds@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: [2.6 patch] fs/block_dev.c:I_BDEV() mustn't be inline
Date: Monday, April 28, 2008 - 11:38 am

This patch fixes the following build error with UML and gcc 4.3:


<--  snip  -->


...

  CC      fs/block_dev.o

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/block_dev.c: In function ‘blkdev_get_block’:

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/block_dev.c:42: sorry, unimplemented: inlining failed in call to ‘I_BDEV’: function body not available

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/block_dev.c:119: sorry, unimplemented: called from here

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/block_dev.c:42: sorry, unimplemented: inlining failed in call to ‘I_BDEV’: function body not available

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/block_dev.c:131: sorry, unimplemented: called from here

make[2]: *** [fs/block_dev.o] Error 1


<--  snip  -->


Signed-off-by: Adrian Bunk <bunk@kernel.org>


---

cd324c3df8a964c6abe03828861238ea3083ba02 diff --git a/fs/block_dev.c b/fs/block_dev.c

index 7d822fa..ce9ea3e 100644

--- a/fs/block_dev.c

+++ b/fs/block_dev.c

@@ -38,7 +38,7 @@ static inline struct bdev_inode *BDEV_I(struct inode *inode)

 	return container_of(inode, struct bdev_inode, vfs_inode);

 }


-inline struct block_device *I_BDEV(struct inode *inode)

+struct block_device *I_BDEV(struct inode *inode)

 {

 	return &BDEV_I(inode)->bdev;

 }


--
[view original message]
From: Linus Torvalds <torvalds@...>
To: Adrian Bunk <bunk@...>
Cc: Ingo Molnar <mingo@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: Re: [2.6 patch] fs/block_dev.c:I_BDEV() mustn't be inline
Date: Monday, April 28, 2008 - 8:41 pm

I'm not going to apply these before I understand what the breakage is all 


There is NO WAY IN HELL this function shouldn't be inlined, and it doesn't

matter a whit if some users outside of this file then also want the

non-inlined version.


The whole setup should result in a single offset-of from the inode, ie

we're talking something that normally generates no code at all when

inlined (because the offset will be subsumed into whatever actually uses

the result).


So just removing the inline is simply not acceptable any more, since it

just implies total and utter breakage of the compiler. At some point you

just have to say: "That is sh*t", and not take it any more.


What is UML doing to trigger this? 


Or should be just tell people that gcc-4.3 is unusable crap?


			Linus

--
[view original message]
From: Adrian Bunk <bunk@...>
To: Linus Torvalds <torvalds@...>
Cc: Ingo Molnar <mingo@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: Re: [2.6 patch] fs/block_dev.c:I_BDEV() mustn't be inline
Date: Tuesday, April 29, 2008 - 4:06 am

cu

Adrian


-- 


       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed


--
[view original message]
From: Sam Ravnborg <sam@...>
To: Adrian Bunk <bunk@...>
Cc: Linus Torvalds <torvalds@...>, Ingo Molnar <mingo@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: Re: [2.6 patch] fs/block_dev.c:I_BDEV() mustn't be inline
Date: Tuesday, April 29, 2008 - 4:17 am

Can you please help me here.

Previously we said: gcc shall inline

Now we say: hi gcc - it is a good idea to inline this


But even without any inline annotation we would expect gcc

to inline it based on normal heuristics simply due to the

small size/footprint of the function.


So I cannot see how the CONFIG_OPTIMIZE_INLINING have any

effect here.

It all smells like a gcc bug to me.


	Sam

--
[view original message]
From: Adrian Bunk <bunk@...>
To: Sam Ravnborg <sam@...>
Cc: Linus Torvalds <torvalds@...>, Ingo Molnar <mingo@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: Re: [2.6 patch] fs/block_dev.c:I_BDEV() mustn't be inline
Date: Tuesday, April 29, 2008 - 5:03 am

Previosly we said:

"inline" means "must inline"


With CONFIG_OPTIMIZE_INLINING=y we say:


gcc anyway has to emit one global copy of this function.


And with the common CONFIG_CC_OPTIMIZE_FOR_SIZE=y we tell gcc to focus 


cu

Adrian


-- 


       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed


--
[view original message]
From: Jeff Dike <jdike@...>
To: Linus Torvalds <torvalds@...>
Cc: Adrian Bunk <bunk@...>, Ingo Molnar <mingo@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>
Subject: Re: [2.6 patch] fs/block_dev.c:I_BDEV() mustn't be inline
Date: Monday, April 28, 2008 - 10:32 pm

Beats the crap out of me.  These things are very generic code from

UML's point of view.


			Jeff


--

Work email - jdike at linux dot intel dot com

--
[view original message]
From: Sam Ravnborg <sam@...>
To: Jeff Dike <jdike@...>
Cc: Linus Torvalds <torvalds@...>, Adrian Bunk <bunk@...>, Ingo Molnar <mingo@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>
Subject: Re: [2.6 patch] fs/block_dev.c:I_BDEV() mustn't be inline
Date: Tuesday, April 29, 2008 - 12:57 am

How does the preprocessed code look like around the definition

and the declaration + use of said function?


Try to do an:

make path/to/file.i


To see the preprocessed output.


Just in case we have some subtle things going on..


	Sam

--
[view original message]
From: Al Viro <viro@...>
To: Linus Torvalds <torvalds@...>
Cc: Adrian Bunk <bunk@...>, Ingo Molnar <mingo@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: Re: [2.6 patch] fs/block_dev.c:I_BDEV() mustn't be inline
Date: Monday, April 28, 2008 - 9:12 pm

AFAICS, it's a gcc bug.  We have

extern struct block_device *I_BDEV(struct inode *inode);

followed by

inline struct block_device *I_BDEV(struct inode *inode)

{

...

}


and presence of declaration with extern within the same translation unit

means that definition we have here is an external one, per 6.7.4.  It's

perfectly legitimate and gcc has no business complaining about inline

here; moreover, example in 6.7.4(7) is essentially the same thing...

--
[view original message]
From: Linus Torvalds <torvalds@...>
To: Al Viro <viro@...>
Cc: Adrian Bunk <bunk@...>, Ingo Molnar <mingo@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: Re: [2.6 patch] fs/block_dev.c:I_BDEV() mustn't be inline
Date: Monday, April 28, 2008 - 9:21 pm

So did the "always_inline" thing just hide this? Or what is going on?


We can just say that gcc-3 has to always_inline if so.


			Linus

--
[view original message]
From: Adrian Bunk <bunk@...>
To: Ingo Molnar <mingo@...>
Cc: Linus Torvalds <torvalds@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: [2.6 patch] fs/buffer.c:init_buffer() mustn't be inline
Date: Monday, April 28, 2008 - 11:38 am

This patch fixes the following build error with UML and gcc 4.3:


<--  snip  -->


...

  CC      fs/buffer.o

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/buffer.c: In function ‘init_page_buffers’:

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/buffer.c:51: sorry, unimplemented: inlining failed in call to ‘init_buffer’: function body not available

/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/buffer.c:1007: sorry, unimplemented: called from here

make[2]: *** [fs/buffer.o] Error 1


<--  snip  -->


Signed-off-by: Adrian Bunk <bunk@kernel.org>


---

922267dbec9ea632537ab61ef9cb2d0d5f9d8f9e diff --git a/fs/buffer.c b/fs/buffer.c

index 39ff144..d74743d 100644

--- a/fs/buffer.c

+++ b/fs/buffer.c

@@ -46,8 +46,7 @@ static int fsync_buffers_list(spinlock_t *lock, struct list_head *list);


 #define BH_ENTRY(list) list_entry((list), struct buffer_head, b_assoc_buffers)


-inline void

-init_buffer(struct buffer_head *bh, bh_end_io_t *handler, void *private)

+void init_buffer(struct buffer_head *bh, bh_end_io_t *handler, void *private)

 {

 	bh->b_end_io = handler;

 	bh->b_private = private;


--
[view original message]
From: Linus Torvalds <torvalds@...>
To: Adrian Bunk <bunk@...>
Cc: Ingo Molnar <mingo@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: Re: [2.6 patch] fs/buffer.c:init_buffer() mustn't be inline
Date: Monday, April 28, 2008 - 12:01 pm

On Mon, 28 Apr 2008, Adrian Bunk wrote:


Can somebody tell why this is not a gcc bug?


		Linus

--
[view original message]
From: Adrian Bunk <bunk@...>
To: Linus Torvalds <torvalds@...>
Cc: Ingo Molnar <mingo@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: Re: [2.6 patch] fs/buffer.c:init_buffer() mustn't be inline
Date: Monday, April 28, 2008 - 12:48 pm

It is a gcc bug.


But having a global function marked as extern was already questionable,

and all assumptions an "inline" would always inline the code are anyway

now broken in your tree.


cu

Adrian


-- 


       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed


--
[view original message]
From: Linus Torvalds <torvalds@...>
To: Adrian Bunk <bunk@...>
Cc: Ingo Molnar <mingo@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: Re: [2.6 patch] fs/buffer.c:init_buffer() mustn't be inline
Date: Monday, April 28, 2008 - 12:58 pm

But when doing this, MARK IT LOUDLY AS A GCC BUG!


The thing is, reading that log message, it was not at all clear why that

change was made. Please make it clear why, rather than quoting a totally

useless error message that doesn't actually tell what is going on.


I agree that having work-arounds for compiler bugs is worth it (assuming

the version is common enough to worry about), but I also don't want to

have unexplained commits doing something that on the face of it is just

odd


Put another way: looking at the actual diff and looking at the commit

message, the only sane reaction from somebody who knows the code is:

"Whaa? WTF?". Saying "This is a gcc bug" would have turned that "WTF?"

into a "Oh, ok then".


			Linus

--
[view original message]
From: Adrian Bunk <bunk@...>
To: Ingo Molnar <mingo@...>
Cc: Linus Torvalds <torvalds@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: [2.6 patch] mm/filemap.c:generic_write_checks() mustn't be inline
Date: Monday, April 28, 2008 - 11:38 am

cu

Adrian


<--  snip  -->


This patch fixes the following build error with UML and gcc 4.3:


<--  snip  -->


...

  CC      mm/filemap.o

/home/bunk/linux/kernel-2.6/git/linux-2.6/mm/filemap.c: In function ‘__generic_file_aio_write_nolock’:

/home/bunk/linux/kernel-2.6/git/linux-2.6/mm/filemap.c:1831: sorry, unimplemented: inlining failed in call to ‘generic_write_checks’: function body not available

/home/bunk/linux/kernel-2.6/git/linux-2.6/mm/filemap.c:2383: sorry, unimplemented: called from here

make[2]: *** [mm/filemap.o] Error 1


<--  snip  -->


Reported-by: Ingo Molnar <mingo@elte.hu>

Signed-off-by: Adrian Bunk <bunk@kernel.org>


---

e4a4374513a2b23060bb385d83f1e67427b1b665 diff --git a/mm/filemap.c b/mm/filemap.c

index 07e9d92..576b553 100644

--- a/mm/filemap.c

+++ b/mm/filemap.c

@@ -1827,7 +1827,8 @@ EXPORT_SYMBOL(iov_iter_single_seg_count);

  * Returns appropriate error code that caller should return or

  * zero in case that write should be allowed.

  */

-inline int generic_write_checks(struct file *file, loff_t *pos, size_t *count, int isblk)

+int generic_write_checks(struct file *file, loff_t *pos, size_t *count,

+			 int isblk)

 {

 	struct inode *inode = file->f_mapping->host;

 	unsigned long limit = current->signal->rlim[RLIMIT_FSIZE].rlim_cur;

--
[view original message]
From: Miklos Vajna <vmiklos@...>
To: Ingo Molnar <mingo@...>
Cc: Linus Torvalds <torvalds@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: Re: [git pull] generic bitops, take 2
Date: Saturday, April 26, 2008 - 1:51 pm

I just hit this bug as well:


        make linux ARCH=um


on i686, gcc 4.3.0, config at

http://uml.nagafix.co.uk/kernels/kernel32-2.6.25.config


Thanks.
[view original message]
From: Sam Ravnborg <sam@...>
To: Ingo Molnar <mingo@...>
Cc: Linus Torvalds <torvalds@...>, Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: Re: [git pull] generic bitops, take 2
Date: Saturday, April 26, 2008 - 1:32 pm

I may be able to explain why..

Before the x68 merge we had an arch/i386/Kconfig.cpu but we did

not have any arch/x86_64/Kconfig.cpu.

When we merged i386 and x86_64 we included the 64 bit stuff in

arch/x86/Kconfig.cpu and thus it became used by both 32bit and 64bit

x86. But during this process we did not do the proper unification

of um - so here we live with the old style.

Blame the one who did the Kconfig unification..


I would assume um should do similar unifaction and get rid of the

i386/x86_64 split (bot I have not looked at doing it).


	Sam

--
[view original message]
From: Ingo Molnar <mingo@...>
To: Linus Torvalds <torvalds@...>
Cc: Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: Re: [git pull] generic bitops, take 2
Date: Saturday, April 26, 2008 - 1:28 pm

so i tried a third build method, gcc 3.4, and that built it fine but UML

crashed during bootup:


 dione:~/linux/linux-x86.q> ./linux

 Core dump limits :

         soft - 0

         hard - NONE

 Checking that ptrace can change system call numbers...OK

 Checking syscall emulation patch for ptrace...OK

 Checking advanced syscall emulation patch for ptrace...OK

 Checking for tmpfs mount on /dev/shm...OK

 Checking PROT_EXEC mmap in /dev/shm/...OK

 Checking for the skas3 patch in the host:

   - /proc/mm...not found: No such file or directory

   - PTRACE_FAULTINFO...not found

   - PTRACE_LDT...not found

 UML running in SKAS0 mode

 Segmentation fault


(gdb) bt

#0  0x000000006020fd92 in txInit ()

#1  0x000000006000a4c1 in init_jfs_fs ()

#2  0x0000000060001794 in do_initcalls ()

#3  0x000000006000196d in do_basic_setup ()

#4  0x0000000060001a14 in kernel_init ()

#5  0x0000000060028427 in run_kernel_thread ()

#6  0x000000006001d020 in new_thread_handler ()

#7  0x0000000000000000 in ?? ()


rip            0x6020fd92       0x6020fd92 <txInit+306>


txInit is in JFS.


but at least i could build UML. (this is all with pristine -git)


So i checked the patch below. And it built fine, and boo^H^Hcrashed just

like it did before:


   - PTRACE_FAULTINFO...not found

   - PTRACE_LDT...not found

 UML running in SKAS0 mode

 Segmentation fault


so i guess this is the way to go?


	Ingo


---------------------->

Subject: uml: kconfig cleanup

From: Ingo Molnar <mingo@elte.hu>

Date: Sat Apr 26 19:10:17 CEST 2008


Signed-off-by: Ingo Molnar <mingo@elte.hu>

---

 arch/um/Kconfig.x86_64 |    7 +++++++

 1 file changed, 7 insertions(+)


Index: linux-x86.q/arch/um/Kconfig.x86_64

===================================================================

--- linux-x86.q.orig/arch/um/Kconfig.x86_64

+++ linux-x86.q/arch/um/Kconfig.x86_64

@@ -1,3 +1,10 @@

+

+menu "Host processor type and features"

+

+source "arch/x86/Kconfig.cpu"

+

+endmenu

+

 config UML_X86

 	bool

...
[ message continues ]
[view original message]
From: Ingo Molnar <mingo@...>
To: Linus Torvalds <torvalds@...>
Cc: Linux Kernel Mailing List <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>, <jdike@...>
Subject: [git pull] generic bitops, take 3
Date: Saturday, April 26, 2008 - 1:50 pm

i think it is. I just put these fixes into the bitops tree and 64-bit

UML seems unaffected and properly picks up these symbols from the x86

Kconfig.cpu file. I pushed out the v3 tree to:


  git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-generic-bitops-v3.git for-linus


find the shortlog and diff below.


this is against your very latest tree (which i rebased against to pick

up the VFS fix). 5 successful build+bootup tests done with this fresh

tree:


 #0, Sat_Apr_26_19_35_34_CEST_2008

 #1, Sat_Apr_26_19_37_02_CEST_2008

 #2, Sat_Apr_26_19_38_48_CEST_2008

 #3, Sat_Apr_26_19_41_36_CEST_2008

 #4, Sat_Apr_26_19_43_28_CEST_2008


on x86, mixed 32-bit/64-bit.


	Ingo


------------------>

Alexander van Heukelum (13):

      x86: change x86 to use generic find_next_bit

      x86, uml: fix uml with generic find_next_bit for x86

      x86, generic: optimize find_next_(zero_)bit for small constant-size bitmaps

      x86: merge the simple bitops and move them to bitops.h

      generic: introduce a generic __fls implementation

      generic: implement __fls on all 64-bit archs

      bitops: use __fls for fls64 on 64-bit archs

      x86: generic versions of find_first_(zero_)bit, convert i386

      x86: switch 64-bit to generic find_first_bit

      x86: optimize find_first_bit for small bitmaps

      x86, UML: remove x86-specific implementations of find_first_bit

      x86: finalize bitops unification

      x86, bitops: select the generic bitmap search functions


Ingo Molnar (2):

      uml: fix build error

      uml: Kconfig cleanup


Joe Perches (1):

      x86: include/asm-x86/pgalloc.h/bitops.h: checkpatch cleanups - formatting only


 arch/um/Kconfig.x86_64             |    7 ++

 arch/um/os-Linux/helper.c          |    1 +

 arch/um/sys-i386/Makefile          |    2 +-

 arch/um/sys-x86_64/Makefile        |    2 +-

 arch/x86/Kconfig.cpu               |    7 ++-

 arch/x86/lib/Makefile              |    3 +-

 arch/x86/lib/bitops_32.c           |   70 -----------...
[ message continues ]
[view original message]
From: Alexander van Heukelum <heukelum@...>
To: Linus Torvalds <torvalds@...>
Cc: Ingo Molnar <mingo@...>, <linux-kernel@...>, Sam Ravnborg <sam@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>
Subject: [PATCH] x86, bitops: select the generic bitmap search functions
Date: Friday, April 25, 2008 - 7:12 am

Introduce GENERIC_FIND_FIRST_BIT and GENERIC_FIND_NEXT_BIT in

lib/Kconfig, defaulting to off. An arch that wants to use the

generic implementation now only has to use a select statement

to include them.


I added an always-y option (X86_CPU) to arch/x86/Kconfig.cpu

and used that to select the generic search functions. This

way ARCH=um SUBARCH=i386 automatically picks up the change

too, and arch/um/Kconfig.i386 can therefore be simplified a

bit. ARCH=um SUBARCH=x86_64 does things differently, but

still compiles fine. It seems that a "def_bool y" always

wins over a "def_bool n"?


Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm>


---


 arch/um/Kconfig.i386 |    8 --------

 arch/x86/Kconfig     |    6 ------

 arch/x86/Kconfig.cpu |    5 +++++

 lib/Kconfig          |    6 ++++++

 4 files changed, 11 insertions(+), 14 deletions(-)


Hello Linus,


I think this is close to what you had in mind?


The patch applies on top of:


git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-generic-bitops.git for-linus


Compile tested um/i386, um/x86_64. Boot-tested using

qemu for i386 and x86_64.


Greetings,

	Alexander


diff --git a/arch/um/Kconfig.i386 b/arch/um/Kconfig.i386

index 49990ea..e09edfa 100644

--- a/arch/um/Kconfig.i386

+++ b/arch/um/Kconfig.i386

@@ -39,14 +39,6 @@ config ARCH_REUSE_HOST_VSYSCALL_AREA

 	bool

 	default y


-config GENERIC_FIND_FIRST_BIT

-	bool

-	default y

-

-config GENERIC_FIND_NEXT_BIT

-	bool

-	default y

-

 config GENERIC_HWEIGHT

 	bool

 	default y

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig

index 004aad8..4d350b5 100644

--- a/arch/x86/Kconfig

+++ b/arch/x86/Kconfig

@@ -77,12 +77,6 @@ config GENERIC_BUG

 	def_bool y

 	depends on BUG


-config GENERIC_FIND_FIRST_BIT

-	def_bool y

-

-config GENERIC_FIND_NEXT_BIT

-	def_bool y

-

 config GENERIC_HWEIGHT

 	def_bool y


diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu

index b9368f5..b94b04e 100644

--- a/arch/x86/Kconfig.cpu

+++ b/arch/x86/Kconfig.cpu

@...
[ message continues ]
[view original message]
From: Harvey Harrison <harvey.harrison@...>
To: Linus Torvalds <torvalds@...>
Cc: Ingo Molnar <mingo@...>, <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>, H. Peter Anvin <hpa@...>, Alexander van Heukelum <heukelum@...>
Subject: Re: [git pull] generic bitops
Date: Thursday, April 24, 2008 - 6:41 pm

config HAVE_GENERIC_FIND_FIRST_BIT

	def_bool n


(I know it defaults to n, but this pattern is becoming suggestive of

features that must be selected, in addition to the HAVE_ prefix)


Although I think for lib stuff, we may want to think about WANT_

prefixes to suggest you have to opt in.


Harvey


--
Previous thread: [git pull] x86 fixes by Ingo Molnar on Thursday, April 24, 2008 - 5:37 pm. (1 message)

Next thread: [PATCH] Minimal mmu notifiers for kvm by Rusty Russell on Thursday, April 24, 2008 - 6:13 pm. (3 messages)