Simon Quigley wrote on 2016/02/22 08:45 -0600:
On Mon, Feb 22, 2016 at 7:29 AM, Filipe Manana <fdman...@gmail.com> wrote:
On Mon, Feb 22, 2016 at 12:02 PM, Simon Quigley <tsimo...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
