> And, even employed, at least I also went through that phase. > (Not to mention I also started by sending small cleanups)
Thank you. I read Linus' statement somewhere, I just can't find it! > 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. I'll RTFM on this one because I don't know what this is. > 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 Should this be documented somewhere? > 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 agree, because the userspace tool probably uses kernel calls of some sort. > 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. I apologize, I'm new around here, I thought Chris was the sole maintainer of all of btrfs. I also wanted his additional feedback, but I guess that isn't really needed. :) For all of you, thank you for taking time to help Philippe and myself out with this. I'm new to kernel development and I'd really like to help out with btrfs because I feel it has serious potential. I'm glad I learned how to submit patches, and I'll look into the resources suggested. In my opinion this should be documented somewhere, a btrfs-specific thing, because I would much rather RTFM then have to wait and ask questions (although the latter still is valuable). If you have any other feedback for beginning kernel development that you would like to share, please, send me an email or PM me on IRC. I'm on #btrfs on Freenode. Thanks, Simon Quigley tsimo...@ubuntu.com tsimonq2 on Freenode -- 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
