linux-ext4 - Re: Work on ext4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 25 Jul 2014 11:07:35 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	"Theodore Ts'o" <tytso@....edu>, Nick Krause <xerofoify@...il.com>
CC:	linux-ext4@...r.kernel.org
Subject: Re: Work on ext4

On 7/25/14, 10:41 AM, Theodore Ts'o wrote:

...

> This will hopefully get you started on the testing side of things,
> which is also a good way to start learning about how ext4 works.
> 
> Cheers,
> 
> 						- Ted

The old adage on IRC is "Don't ask to ask; ask."  In
development-land, it's more like "Don't ask to help; help."

The trick is knowing what constitutes "help."  Asking for
detailed instruction is not "help."

Over on the btrfs-list, Hugo had a good set of suggestions as
well; some are btrfs-specific, but in general, good advice for
anyone trying to get engaged with an upstream project:

>From Hugo -

...

>    My recommendations for you, if you want to work on btrfs, are:
> 
>  * Build and install the latest kernel from Linus's git repo
> 
>  * Read and understand the user documentation [2]
> 
>  * Create one or several btrfs filesystems with different
>    configurations and learn how they work in userspace -- what are the
>    features, what are the problems you see? Actually use at least one
>    of the filesystems you created for real data in daily use (with
>    backups)
> 
>  * Build the userspace tools from git
> 
>  * Pick up one of the userspace projects from [3] and implement that.
>    If you pick the right one(s), you'll have to learn about some of
>    the internal structures of the FS anyway. Compile and test your
>    patch. If you're adding a new feature, write an automated xfstest
>    for it as well.
> 
>  * Get that patch accepted. This will probably involve a sequence of
>    revisions to it, multiple versions over a period of several weeks
>    or more, with a review process. You should also send your test to
>    xfstests and get that accepted.
> 
>  * Do the above again, until you get used to the processes involved,
>    and have demonstrated that you can work well with the other people
>    in the subsystem, and are generally producing useful and sane code.
>    It's all about trust -- can you be trusted to mostly do the right
>    thing? (So far on linux-kernel, you've rather demonstrated the
>    opposite: your intentions are good, but your execution leaves a lot
>    to be desired)
> 
>  * Use the documentation at [4], and the output of btrfs-debug-tree to
>    understand the internal structure of the FS
> 
>  * Pick up one of the smaller, more self-contained ideas from the
>    projects page [5] (say, [6] or [7]) and try to implement it. Again:
>    build, write test code, test thoroughly, submit patch for review,
>    modify as suggested by reviewers, and repeat as often as necessary
> 
>    Hugo.


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