Re: [PATCH] Btrfs: ctree: reduce args where only fs_info used

From: Daniel Dressler
Date: Fri Nov 21 2014 - 11:03:39 EST


Ah thanks David for looking at this.

Sorry for the thin paragraphs my vim was warming too early about long
lines. I will reformat it to break at 74 chars.

No problem, I'll redo everything so it is one function per patch. Now
fair warning: there are about 102 functions to cleanup. I was a bit
worried that many patches would cause too much maintainer overhead but
it is no problem for me. Only a few functions have dependecies on
other functions needing cleanup. Thus there will be some small patch
series for those function sets. A big benefit of one function one
patch is that extent-io.c will no longer be a 34 function monster
patch.

Thank you David, I'll redo all these patches.

Is there any rate limiting I should be doing? I don't want to flood
the list with burst of dozen plus patches, or is that an okay volume?

Daniel

2014-11-22 0:55 GMT+09:00 David Sterba <dsterba@xxxxxxx>:
> On Wed, Nov 12, 2014 at 01:43:09PM +0900, Daniel Dressler wrote:
>> This patch is part of a larger project to cleanup
>> btrfs's internal usage of struct btrfs_root. Many
>> functions take btrfs_root only to grab a pointer
>> to fs_info.
>
> Thanks for picking up the project.
>
> A mere formality, can you please justify the paragraphs to 74 chars?
>
> --
> This patch is part of a larger project to cleanup btrfs's internal usage
> of struct btrfs_root. Many functions take btrfs_root only to grab a
> pointer to fs_info.
> --
>
>> This patch does not address the two functions in
>> ctree.c (insert_ptr, and split_item) which only
>> use root for BUG_ONs in ctree.c
>>
>> This patch affects the following functions:
>> 1) fixup_low_keys
>> 2) btrfs_set_item_key_safe
>
> Please send one patch per function change, unless there are more that
> are somehow entangled that it would make it hard to separate.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/