lkml.org 
[lkml]   [2009]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Btrfs for mainline
From
Date
On Sat, 2009-01-03 at 01:37 +0900, Ryusuke Konishi wrote:
> Hi,
> On Wed, 31 Dec 2008 18:19:09 -0500, Chris Mason <chris.mason@oracle.com> wrote:
> >
> > This has only btrfs as a module and would be the fastest way to see
> > the .c files. btrfs doesn't have any changes outside of fs/Makefile and
> > fs/Kconfig
>
> I found some overlapping (or cloned) functions in
> btrfs-unstable.git/fs/btrfs, for example:
>
> - Declarations to apply hardware crc32c in fs/btrfs/crc32c.h:
> The same code is found in arch/x86/crypto/crc32c-intel.c
>

Yes, I can just remove the btrfs version of this for now.

> - btrfs_wait_on_page_writeback_range() and btrfs_fdatawrite_range():
> These are clones of wait_on_page_writeback_range() and
> __filemap_fdatawrite_range() respectively, and can be removed if they
> are just exported.
>
> - Copies of add_to_page_cache_lru() found in compression.c and extent_io.c
> (can be replaced if it's exported)
>
> How about including patches to resolve these in the btrfs kernel tree
> (or patchset to be posted) ?
>

My plan was to export those after btrfs was actually in. But on Monday
I'll send along a patch to export them and make compat functions in
btrfs.

> In addition, there seem to be well-separated reusable routines such as
> async-thread (enhanced workqueue) and extent_map. Do you intend to
> move these into lib/ or so?
>
> I also tried scripts/checkpatch.pl against btrfs, and it has detected
> 45 ERRORs and 93 WARNINGs. I think it's a good opportunity to clean
> up these violations.

Good point, thanks for looking at the code.

-chris




\
 
 \ /
  Last update: 2009-01-02 19:11    [W:0.371 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site