Hi Andreas, On Sun, Apr 28, 2013 at 3:09 AM, Andreas Dilger <adilger@xxxxxxxxx> wrote: > > Tao, > thanks for starting to look into this. > Thank you for not complaining me creating more work for you :) > Does it really make sense to stage a filesystem under drivers/*? > IMHO it makes a lot more sense to put the components into the > location where they would live in the upstream kernel tree (i.e. > fs/lustre and net/lnet). > This is how current patches are created. And I agree with you that putting the code in fs/lustre and net/lnet and depending on CONFIG_STAGING will be more convenient for future development. It is also what Trond suggested in last year's LSF-MM summit. Personally I am OK with either way though. So it is indeed a question to Greg and Al: Do you have any objections if we put lustre client code in fs/lustre and net/lnet, depending it on CONFIG_STAGING? Thanks very much! > Also a question for you - what version of the Lustre client > are you intending to submit to the staging tree? We are very close > to the 2.4.0 release, so it definitely makes sense to start with > that one. > The current patch was created before LUG 2013, based on Whamcloud's master HEAD at that time, plus several under-review patches in Intel Jira to get 3.8/3.9 kernel support and code extraction. I will create the new big patch based on the current master HEAD which is closer to the 2.4.0 release. And future patches can be ported to staging client incrementally. Does it sound OK to you? > There is also the question of how you will keep the staging client > in-sync with the development done in the upstream Lustre repo? > Certainly patches will be ported between staging client and the development done in Lustre repo back and forth. All bugfix and new feature patches will be ported to staging client. Cleanup patches will also be ported to Lustre repo when necessary. As HCH once mentioned, it is a price we must pay to get a long-time out-of-tree file system mainlined :-) > There has definitely been a lot of work done to clean up the > Lustre code, but there is still a considerable amount of work > left to be done. In particular, the CLIO layer needs a bunch of > cleanup to become more efficient and understandable. > I agree that there is still a fair amount of work left. IMHO, the CLIO layer cleanup is more about coping with upstream kernel's readahead/writeback mechanisms and thus it should more or less involve Al, Christoph and maybe others' (like Fengguang Wu's) opinions. So it can be done during the staging time. Thanks for your strong support all the time! Best Regards, Tao -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
