On Fri, Sep 01, 2017 at 01:15:45PM +0800, Qu Wenruo wrote: > On 2017年09月01日 11:36, Anthony Riley wrote: > >Hey folks, > > > >I thought I would finally take a swing at things I've wanted to be an > >kernel/fs dev fora few years now. My current $job is as an > >Infrastructure Engineer. I'm currently teaching myself C and have > >background in shell scripting & python. I love doing deep dives and > >learning about linux internals. I've read the btrfs.wiki and can't > >really decide which project to choose to start. > > > >Also should I go through this https://kernelnewbies.org/FirstKernelPatch first? > >Or should i start with something in Userspace? > > Well, personally I strongly recommended to start with btrfs on-disk > format first, and then btrfs-progs/test cases, and kernel > contribution as final objective. Pick a project which bothers you -- is there some feature that you want to have, or a particular bug, or a sharp corner that needs rounding off? This next bit is purely my opinion. Feel free to ignore it if it doesn't float your boat. For a relatively easy example (from a code point of view), there's a bug with send-receive where stuff breaks if you try snapshotting and then sending a subvolume which already has a received-uuid set. There's probably several ways of dealing with this. Alongside this, there's also a requirement for being able to do round-trip send/receive while preserving the ability to do incremental sends. This is likely to be related to the above bug-fix. I did a complete write-up of what's happening, and what needs to happen, here: http://www.spinics.net/lists/linux-btrfs/msg44089.html If you can fix the first bug in a way that doesn't rule out the round-trip work, that's great. If you can also get the round-trip stuff working, that's even better (but be warned that it will get postponed until kdave is ready for all the stream format changes to happen at once). > BTW, if you want to start with btrfs on-disk format, print-tree.c > from btrfs-progs is a good start point and btrfs wiki has relatively > well documented entry for it. Seconded on this. For the on-disk format, it's also useful to create a small test filesystem and use btrfs-debug-tree on it as you do stuff to it (create files, create subvols, make links, modify files). Do this in conjunction with the "Data Structures" page, and you can see how it all actually fits together. It took me a couple of weeks to learn how it all worked the first time round, but I didn't have much detailed documentation to work from back then. Since you speak python, there's also Hans's python-btrfs: https://github.com/knorrie/python-btrfs > https://btrfs.wiki.kernel.org/index.php/Btrfs_design > https://btrfs.wiki.kernel.org/index.php/Btree_Items And, more generally: https://btrfs.wiki.kernel.org/index.php/Main_Page#Developer_documentation I'd also point out the Data Structures and Trees pages linked there. Some of the information is a bit out of date, or represents a prototype of what it's describing. The source code is canonical -- use the documentation as a guide to help you see where in the source to look. Hugo. -- Hugo Mills | I'm always right. But I might be wrong about that. hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 |
Attachment:
signature.asc
Description: Digital signature
