[PATCH] Btrfs: fix build errors of extent_io.c

[PATCH] Btrfs: fix build errors of extent_io.c

[Ryusuke Konishi]

Hi Chris,

I've started to read and try btrfs, and soon met the following build
errors.  The attached patch fixes the problem.

Could you check this?

Regards,
Ryusuke Konishi
--
Btrfs: fix build errors of extent_io.c

This will fix the following compile-time errors:

fs/btrfs/extent_io.c: At top level:
fs/btrfs/extent_io.c:815: error: __ksymtab_set_extent_bit causes a section type conflict
fs/btrfs/extent_io.c:815: error: __ksymtab_set_extent_bit causes a section type conflict
fs/btrfs/extent_io.c:156: error: __ksymtab_free_extent_state causes a section type conflict
fs/btrfs/extent_io.c:156: error: __ksymtab_free_extent_state causes a section type conflict
fs/btrfs/extent_io.c:137: error: __ksymtab_alloc_extent_state causes a section type conflict
fs/btrfs/extent_io.c:137: error: __ksymtab_alloc_extent_state causes a section type conflict
make[2]: *** [fs/btrfs/extent_io.o] Error 1
make[1]: *** [fs/btrfs] Error 2

Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
---
 fs/btrfs/extent_io.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 25ce2d1..b6c69ef 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -112,7 +112,7 @@ void extent_io_tree_init(struct extent_io_tree *tree,
 }
 EXPORT_SYMBOL(extent_io_tree_init);
 
-static struct extent_state *alloc_extent_state(gfp_t mask)
+struct extent_state *alloc_extent_state(gfp_t mask)
 {
 	struct extent_state *state;
 #ifdef LEAK_DEBUG
@@ -136,7 +136,7 @@ static struct extent_state *alloc_extent_state(gfp_t mask)
 }
 EXPORT_SYMBOL(alloc_extent_state);
 
-static void free_extent_state(struct extent_state *state)
+void free_extent_state(struct extent_state *state)
 {
 	if (!state)
 		return;
@@ -661,7 +661,7 @@ static void set_state_bits(struct extent_io_tree *tree,
  * [start, end] is inclusive
  * This takes the tree lock.
  */
-static int set_extent_bit(struct extent_io_tree *tree, u64 start, u64 end, int bits,
+int set_extent_bit(struct extent_io_tree *tree, u64 start, u64 end, int bits,
 		   int exclusive, u64 *failed_start, gfp_t mask)
 {
 	struct extent_state *state;
-- 
1.5.6.5

Re: [PATCH] Btrfs: fix build errors of extent_io.c

[Chris Mason]

On Wed, 2008-12-24 at 17:56 +0900, Ryusuke Konishi wrote:
> Hi Chris,
> 
> I've started to read and try btrfs, and soon met the following build
> errors.  The attached patch fixes the problem.
> 
> Could you check this?
> 

Strange, I wonder why your gcc complains and mine doesn't ;)  I'll fix
these up thouhg.

-chris

Re: [PATCH] Btrfs: fix build errors of extent_io.c

[Ryusuke Konishi]

2009/1/6 Chris Mason <chris.mason@oracle.com>:
> On Wed, 2008-12-24 at 17:56 +0900, Ryusuke Konishi wrote:
>> Hi Chris,
>>
>> I've started to read and try btrfs, and soon met the following build
>> errors.  The attached patch fixes the problem.
>>
>> Could you check this?
>>
>
> Strange, I wonder why your gcc complains and mine doesn't ;)  I'll fix
> these up thouhg.

Because I tried it on a powerpc ;)
The check of EXPORT_SYMBOL macros seems to be more strict
than that of x86.

As you can tell, my intention was to test endian problems,
and, so far, btrfs is perfectly working on both architectures
(except I met a freeze due to a disk full).
I mean the compatibilty of disk image was achieved between
x86 and ppc64 without problems.

Ryusuke

Re: [PATCH] Btrfs: fix build errors of extent_io.c

[Christoph Hellwig]

On Tue, Jan 06, 2009 at 02:29:17AM +0900, Ryusuke Konishi wrote:
> 2009/1/6 Chris Mason <chris.mason@oracle.com>:
> > On Wed, 2008-12-24 at 17:56 +0900, Ryusuke Konishi wrote:
> >> Hi Chris,
> >>
> >> I've started to read and try btrfs, and soon met the following build
> >> errors.  The attached patch fixes the problem.
> >>
> >> Could you check this?
> >>
> >
> > Strange, I wonder why your gcc complains and mine doesn't ;)  I'll fix
> > these up thouhg.
> 
> Because I tried it on a powerpc ;)
> The check of EXPORT_SYMBOL macros seems to be more strict
> than that of x86.

It doesn't really matter how strict the checks are, because the exports
simply need to go away.  As long as the extent_map/buffer code resides
inside btrfs no one should be using it without either copying it or
moving it out of the btrfs module and into a common one first.

Re: [PATCH] Btrfs: fix build errors of extent_io.c

[Chris Mason]

On Mon, 2009-01-05 at 12:37 -0500, Christoph Hellwig wrote:
> On Tue, Jan 06, 2009 at 02:29:17AM +0900, Ryusuke Konishi wrote:
> > 2009/1/6 Chris Mason <chris.mason@oracle.com>:
> > > On Wed, 2008-12-24 at 17:56 +0900, Ryusuke Konishi wrote:
> > >> Hi Chris,
> > >>
> > >> I've started to read and try btrfs, and soon met the following build
> > >> errors.  The attached patch fixes the problem.
> > >>
> > >> Could you check this?
> > >>
> > >
> > > Strange, I wonder why your gcc complains and mine doesn't ;)  I'll fix
> > > these up thouhg.
> > 
> > Because I tried it on a powerpc ;)
> > The check of EXPORT_SYMBOL macros seems to be more strict
> > than that of x86.
> 
> It doesn't really matter how strict the checks are, because the exports
> simply need to go away.  As long as the extent_map/buffer code resides
> inside btrfs no one should be using it without either copying it or
> moving it out of the btrfs module and into a common one first.

Yes, my plan was to drop the exports.

-chris

Re: [PATCH] Btrfs: fix build errors of extent_io.c

[Ryusuke Konishi]

2009/1/6 Chris Mason <chris.mason@oracle.com>:
> On Mon, 2009-01-05 at 12:37 -0500, Christoph Hellwig wrote:
>> On Tue, Jan 06, 2009 at 02:29:17AM +0900, Ryusuke Konishi wrote:
>> > 2009/1/6 Chris Mason <chris.mason@oracle.com>:
>> > > On Wed, 2008-12-24 at 17:56 +0900, Ryusuke Konishi wrote:
>> > >> Hi Chris,
>> > >>
>> > >> I've started to read and try btrfs, and soon met the following build
>> > >> errors.  The attached patch fixes the problem.
>> > >>
>> > >> Could you check this?
>> > >>
>> > >
>> > > Strange, I wonder why your gcc complains and mine doesn't ;)  I'll fix
>> > > these up thouhg.
>> >
>> > Because I tried it on a powerpc ;)
>> > The check of EXPORT_SYMBOL macros seems to be more strict
>> > than that of x86.
>>
>> It doesn't really matter how strict the checks are, because the exports
>> simply need to go away.  As long as the extent_map/buffer code resides
>> inside btrfs no one should be using it without either copying it or
>> moving it out of the btrfs module and into a common one first.
>
> Yes, my plan was to drop the exports.
>
> -chris

I agree with it, too.
The patch was just to let you know the problem at the time of
Chrismas.

Ryusuke