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:	Mon, 28 Jul 2014 00:01:54 -0400
From:	Nick Krause <xerofoify@...il.com>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	"Theodore Ts'o" <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: Work on ext4

On Fri, Jul 25, 2014 at 12:07 PM, Eric Sandeen <sandeen@...hat.com> wrote:
> 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.
>
>

I have got some work in brtfs for now , Ted so I won't
be able to run the tests for you for the next few weeks
probably. Sorry about the issues, but brtfs seems
more work then ext4 as of this point in time.
Nick
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ