On Sun, Apr 28, 2013 at 10:54:12AM +0800, Peng Tao wrote: > On Sun, Apr 28, 2013 at 3:09 AM, Andreas Dilger <adilger@xxxxxxxxx> wrote: > > 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! I will not touch any code outside of drivers/staging/ so you need to coordinate this with the network and fs maintainers if you don't want the code in drivers/staging/ Personally, I'd recommend not putting it in fs/ and net/ because it really isn't ready for that part of the kernel. Also, no one will realize it is there to be cleaned up, so you will not get help from others on this. Also, the TAINT_CRAP will not apply to your code, which is usually not a good thing, because you want your users to realize this. And yes, we have had filesystems under drivers/staging. Heck, we had a whole subarch in there for a while, as long as it's self-contained, I don't have a probelm with it. But, if you are just trying to get around the Red Hat rule that they don't enable drivers in drivers/staging/ well, that's some politics that I don't want to get in the middle of. So, again, I'll gladly take the code in drivers/staging/ whenever you can send me the patch. If you don't want it there, then I can't help you out. It's your call, greg k-h -- 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
