Re: [PATCH] Btrfs: fix build errors of extent_io.c
On Tue, Jan 06, 2009 at 02:29:17AM +0900, Ryusuke Konishi wrote: 2009/1/6 Chris Mason chris.ma...@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. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Btrfs: fix build errors of extent_io.c
2009/1/6 Chris Mason chris.ma...@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.ma...@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 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Btrfs: fix build errors of extent_io.c
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.ryus...@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
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
