<div dir="ltr">(added lustre-devel, since there's good backstory for others here)<div class="gmail_extra"><br></div><div class="gmail_extra">Don't worry if you aren't an expert in C - much of the initial cleanup is easy. Just mop up a file, and make sure the kernel still builds again. There's a good guide on working with the linux-next kernel here:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://www.kernel.org/doc/man-pages/linux-next.html">https://www.kernel.org/doc/man-pages/linux-next.html</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I've been following these directions to send an emailed patch series:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://burzalodowa.wordpress.com/2013/10/05/how-to-send-patches-with-git-send-email/">https://burzalodowa.wordpress.com/2013/10/05/how-to-send-patches-with-git-send-email/</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">We should probably keep these cleanups in one big patch series, to ease upstream adoption. I suggest branching linux-next (I'm working off the 20150518 tag currently), and committing things as you finish mopping them up with git commit -s <file>. That way, git automatically inserts the "Signed-off-by" line for you. If you send a patch series over to me, I'll sign it off as well, and fold it into the series I'm regularly posting. You can do that with the following:</div><div class="gmail_extra"><br></div><div class="gmail_extra">git format-patch --subject-prefix="PATCH" -o <output dir> -<# commits in series></div><div class="gmail_extra">git send-email -<# commits> --subject-prefix="PATCH" --to=<dest email> <output dir></div><div class="gmail_extra"><br></div><div class="gmail_extra">BTW, adding --compose to the git send-email line will pop up an editor, to write an introduction to the series (the [PATCH 0/8] email, introducing the set). Be sure your commits include a single-line comment summarizing the change, a blank line, a more verbose (if needed) comment, another blank line, and then the Signed-off-by header. Otherwise the kernel gatekeepers have trouble merging, and you'll be dinged on syntax.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If I can help in any way, please let me know.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">--<br>Mike Shuey</div></div>
<br><div class="gmail_quote">On Thu, May 21, 2015 at 1:53 PM, Drokin, Oleg <span dir="ltr"><<a href="mailto:oleg.drokin@intel.com" target="_blank">oleg.drokin@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The procedure is to use git send-email (with --annotation if more than one patch) and that would generate the diffstats and other stuff.<br>
<div class=""><div class="h5"><br>
On May 21, 2015, at 1:32 PM, Chris Hanna wrote:<br>
<br>
> Hi Mike,<br>
><br>
> Great, I'll work on the osc for starters. I should also warn that I'm<br>
> not an expert in C, I'm just an admin of an XSEDE resource that isn't in<br>
> production yet, so I have some free cycles. I will run checkpatch on<br>
> anything I build and double-check. I'll keep my old K&R C book handy<br>
> for good luck.<br>
><br>
> Is the procedure, like you've done already, to mail Oleg and CC<br>
> <a href="mailto:devel@driverdev.osuosl.org">devel@driverdev.osuosl.org</a>, <a href="mailto:gregkh@linuxfoundation.org">gregkh@linuxfoundation.org</a>,<br>
> <a href="mailto:kernel-janitors@vger.kernel.org">kernel-janitors@vger.kernel.org</a>, <a href="mailto:linux-kernel@vger.kernel.org">linux-kernel@vger.kernel.org</a> and HPDD<br>
> list with the git stats and full git patch?<br>
><br>
> I can post future mailings to lustre-devel, I'm already subscribed.<br>
><br>
> Thanks,<br>
><br>
> Chris<br>
><br>
> On 5/21/15 11:55 AM, Michael Shuey wrote:<br>
>> Chris, good to virtually meet you!<br>
>><br>
>> I don't know of anyone (other than myself) submitting cleanup patches for<br>
>> linux-next, though there are a number of patches under LU-6215 and LU-6142<br>
>> in the HPDD tree that do some cleanups.<br>
>><br>
>> I've mostly been focusing on cleaning the lnet part of the tree; if you<br>
>> wanted to start in on some of the lustre parts, that would be great. I've<br>
>> been breaking the task up into multiple phases:<br>
>><br>
>> 1) clean whitespace - tabs, not spaces, to indent; fix variable alignment<br>
>> in headers, and change variable declaration blocks to use a single space<br>
>> (between type & variable)<br>
>><br>
>> 2) eliminate obvious dead code<br>
>><br>
>> 3) fix remaining <a href="http://checkpatch.pl" target="_blank">checkpatch.pl</a> issues (underway now)<br>
>><br>
>> 4) (TBD) sync code with HPDD's tree<br>
>><br>
>> If you wanted to start down on lustre/osc and lustre/ptlrpc, that'd be<br>
>> good. I'm collecting patches against both the <a href="http://kernel.org" target="_blank">kernel.org</a> tree and the HPDD<br>
>> tree, to propagate dead code removal to HPDD (and largely ignoring<br>
>> formatting and <a href="http://checkpatch.pl" target="_blank">checkpatch.pl</a> fixes for HPDD right now). Any patching you<br>
>> can provide would be most appreciated!<br>
>><br>
>> BTW, we should probably spin up a mail thread about this somewhere more<br>
>> public. Are you on lustre-devel, and would you mind posting future<br>
>> coordination emails to the whole list?<br>
>><br>
>> --<br>
>> Mike Shuey<br>
>><br>
>> On Wed, May 20, 2015 at 2:22 PM, Chris Hanna <<a href="mailto:hannac@iu.edu">hannac@iu.edu</a>> wrote:<br>
>><br>
>>> Greetings!<br>
>>><br>
>>> I should have some time this week to work on this, any suggestions for<br>
>>> where I could start in Greg's linux-next tree? Is anyone doing format<br>
>>> cleanup on '/drivers/staging/lustre/lustre/osc/', for example? I don't<br>
>>> want to duplicate something already in process.<br>
>>><br>
>>> Thanks,<br>
>>> Chris<br>
>>><br>
>>> On 5/15/15 4:02 PM, Drokin, Oleg wrote:<br>
>>>> Hello!<br>
>>>><br>
>>>> On May 15, 2015, at 10:19 AM, Michael Shuey wrote:<br>
>>>><br>
>>>>> I'm relatively new to <a href="http://kernel.org" target="_blank">kernel.org</a> development, and completely new to<br>
>>> lustre development - so be warned, I'll have many newbie questions. That<br>
>>> said, I'd very much like to help ensure lustre stays in the upstream<br>
>>> kernel, and do whatever I can to shift as much development upstream as<br>
>>> possible. At the moment, I've been looking at trivial cleanups<br>
>>> (indentation, dead code removal, etc.) as a means to learn how to send<br>
>>> patches upstream. I'm happy to continue this, and begin eliminating<br>
>>> checkpatch warnings as well. It's a good learning exercise, and once I<br>
>>> have a rhythm for submitting patches and testing I can bring in some of my<br>
>>> team and move on to other tasks on the list.<br>
>>>>> That said, I've got some logistics questions...<br>
>>>>><br>
>>>>> 1) What development mailing lists should I track?<br>
>>>>><br>
>>>>> I follow lustre-discuss and lustre-devel, and hpdd-discuss. Is there<br>
>>> an hpdd-devel, where major code shifts are discussed? Or is discussion<br>
>>> primarily through developer days, issue trackers, and out-of-band mail<br>
>>> threads like this?<br>
>>>> hpdd-disuss is currently the designated place to send patches to.<br>
>>> lustre-devel is where we'd eventually shift.<br>
>>>> That said, sadly there are not too much public discussions of things<br>
>>> frequently because stuff is usually developed by a single company.<br>
>>>> So most of discussion is happening at developer days and forums like<br>
>>> opensfs CWG. Also email threads and tickets.<br>
>>>>> 2) Is there a current "getting started with Lustre dev" guide?<br>
>>>>><br>
>>>>> There's little documentation on <a href="http://lustre.org" target="_blank">lustre.org</a> about managing development<br>
>>> - and what I've found tends to be either very old (e.g., Oracle days) or<br>
>>> incomplete (e.g., developer day slides, where specifics were only covered<br>
>>> in person). Is there a more current guide? Or should I bug Morrone for an<br>
>>> account on <a href="http://lustre.org" target="_blank">lustre.org</a>, and build such a guide in his wiki? I'm happy to<br>
>>> add documentation as well\u2026<br>
>>>> For community tree lustre )meaning not the in-kernel thing) it's<br>
>>> <a href="https://wiki.hpdd.intel.com/display/PUB/Lustre+Development" target="_blank">https://wiki.hpdd.intel.com/display/PUB/Lustre+Development</a><br>
>>>> in particular <a href="https://wiki.hpdd.intel.com/display/PUB/Submitting+Changes" target="_blank">https://wiki.hpdd.intel.com/display/PUB/Submitting+Changes</a><br>
>>>><br>
>>>>> 2) What's the end goal here, between <a href="http://kernel.org" target="_blank">kernel.org</a> and HPDD trees?<br>
>>>>><br>
>>>>> HPDD and <a href="http://kernel.org" target="_blank">kernel.org</a> maintain two separate trees. Presumably patches<br>
>>> should be developed for both, correct? If so, will parts of the HPDD tree<br>
>>> be going away at any point - to be supplanted by <a href="http://kernel.org" target="_blank">kernel.org</a>? I know Greg<br>
>>> KH has indicated that development should occur in <a href="http://kernel.org" target="_blank">kernel.org</a> - but that<br>
>>> may not be possible, given the need to support older vendor kernels.<br>
>>> HPDD's tree isn't really upstream for <a href="http://kernel.org" target="_blank">kernel.org</a>, either - there's a<br>
>>> number of pieces that can't go in right now.<br>
>>>>> Where is this going?<br>
>>>> This is a complicated question, really.<br>
>>>><br>
>>>> Initially EMC rammed this thing in, since supposedly it gives you "free"<br>
>>> update of codebase to support newer kernels.<br>
>>>> Well, it did not pan out exactly as planned and they bailed out. Now we<br>
>>> get to keep the pieces.<br>
>>>> Having the client in the tree is indeed good for it being updated for<br>
>>> in-kernel API changes and stuff.<br>
>>>> Currently it's a liability, though since we need to maintain<br>
>>> compatibility with this somewhat old code snapshot and no new features<br>
>>> could be added.<br>
>>>> Ideally in the end it would be a fully featured up to date client that<br>
>>> would be shipped by major distros.<br>
>>>> Also having this code fully accepted means certain things we'd like<br>
>>> added to kernel APIs is easier to justify since the main argument of "no<br>
>>> code in kernel uses this" goes away.<br>
>>>> I feel like we wound not be able to fully drop client support from our<br>
>>> hpdd tree in any foreseeable future because we need compatibility with all<br>
>>> old distros that don't ship new enough kernel.<br>
>>>> And then once they all start carrying it, they'd probably won't have any<br>
>>> moedrn features too so there would still be place for a backported client<br>
>>> or something.<br>
>>>>> 3) How do patches go into HPDD's tree?<br>
>>>>><br>
>>>>> I've found some slides from Andreas; I'm starting to understand what<br>
>>> role Jenkins, Gerrit, and the HPDD tree play. How does one get patches<br>
>>> into this? git send-email to a list, bug someone for an account on Gerrit,<br>
>>> or what? Or should I not be looking at the HPDD tree, and only staring at<br>
>>> <a href="http://kernel.org" target="_blank">kernel.org</a>'s tree?<br>
>>>> <a href="https://wiki.hpdd.intel.com/display/PUB/Submitting+Changes" target="_blank">https://wiki.hpdd.intel.com/display/PUB/Submitting+Changes</a><br>
>>>><br>
>>>> You'll need to create your own account in gerrit and use that to submit<br>
>>> patches.<br>
>>>> For upstream kernel work, you should not really be looking into hpdd<br>
>>> tree much other than submitting same patches to hpdd tree for stuff like<br>
>>> unneeded proc files removal and tools updates.<br>
>>>> Bye,<br>
>>>> Oleg<br>
>>><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>