Re: [Question]: Contributing to btrfs

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

Simon Quigley wrote on 2016/02/22 08:45 -0600:
> On Mon, Feb 22, 2016 at 7:29 AM, Filipe Manana <fdmanana@gmail.com> wrote:
>> On Mon, Feb 22, 2016 at 12:02 PM, Simon Quigley <tsimonq2@ubuntu.com> wrote:
>>>> 1) You don't learn anything by doing them. You don't learn nothing
>>>> about btrfs internals, filesystems in general, kernel programming in
>>>> general, general programming in C, etc. It ends up being only a waste
>>>> of time for you;
>>>
>>> It is useful for one reason. If you would like to get used to the workflow of kernel development,
>>
>> No, that's silly. Generating a patch file and sending it to the
>> mailing list is very trivial. There's not much to learn there.
>> Certainly you don't need to send around 10 whitespace/style patches
>> for that. 1 is enough to "test the waters". And most people learn that
>> by observing others for a while too.
>>
>>> this seems to be useful for a lot of people. In fact, Linus himself has encouraged this.
>>
>> Whitespace/style patches I doubt. He probably encourages for small
>> cleanup/optimizations as the first patch, like he did recently at
>> https://lkml.org/lkml/2015/9/15/919. That's something that requires
>> some thinking and understanding. Now running checkpatch and fix its
>> warnings, doesn't require any skill at all.
>> What were you planning? Sending more 100 patches, each one to fix a
>> different style issue for each function? There's probably hundreds or
>> thousands more style/whitespace "issues" to fix in btrfs alone.
>>
>> Just think about what you want to accomplish. It's normal to not know
>> what do initially, I think everyone goes through that phase, specially
>> if not employed to work on btrfs (or whatever project interests you).

And, even employed, at least I also went through that phase.
(Not to mention I also started by sending small cleanups)

>> Just read code, find issues in it, make changes for your own testing,
>> read bug reports and performance issue reports here in the list and in
>> kernel's bugzilla - some bugs might be easy to fix, other might
>> require very deep knowledge of the internals or no one figured out yet
>> how to reproduce. Or run xfstests and filesystem stress testing tools
>> to find problems (there's plenty of races, deadlocks, etc that happen
>> often and no one knows about them yet). Over time you'll find plenty
>> of things to do, that make you learn a lot and do something useful for
>> users and other developers.

Despite reading the code, which sometimes is quite boring and easy to 
get lost especially when you are not familiar with btrfs,
personally I recommend to start from btrfs on-disk format with 
btrfs-dedup-tree.

And my personal quick-and-dirty skill up roadmap would be:
1) Understand btrfs on-disk format
2) btrfs-progs contributor
3) btrfs kernel contributor

On-disk data is static and you don't need to care any of the complicated 
implementation or details.
All you need to care is, what is on disk, what's the meaning of that 
on-disk data, and how on-disk data change after you did something with 
the btrfs filesystem, like creating a empty file/dir, or write some data 
into it.

Also, when you play with btrfs-debug-tree, it's quite easy to get 
familiar how btrfs-debug-tree works, and maybe found some easy 
enhancement for btrfs-debug-tree.

On-disk format also provides a super good entry point for further reading.

If you want to understand how btrfs inserts file extents, as long as you 
find file extents use EXTENT_DATA key type, you can easily find the 
direct code which inserts that key into btrfs btree.


With btrfs-debug-tree as a learning tool, you will be quite easy to 
begin your contribution to btrfs-progs, like adding some output which 
current btrfs-debug-tree lacks.

After you're familiar with btrfs-progs enough, all skills learnt will 
help you to start your kernel contribution, although kernel is never as 
easy as btrfs-progs, but I think that's your object.

>
> I guess you have a point, I apologize. Overall though, I am curious as
> to what Chris Mason has to say about this.

I think David, one of the kernel maintainers and btrfs-progs maintainer, 
and Filipe, one of the core and the most active developer, their words 
have carries a lot of weight.

Thanks,
Qu


> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>