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 <[email protected]>: > 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
