On Fri, Jun 01, 2018 at 02:30:49PM -0400, Andreas Dilger wrote: > On Jun 1, 2018, at 5:11 AM, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > The Lustre filesystem has been in the kernel tree for over 5 years now. > > While it has been an endless source of enjoyment for new kernel > > developers learning how to do basic codingstyle cleanups, as well as an > > semi-entertaining source of bewilderment from the vfs developers any > > time they have looked into the codebase to try to figure out how to port > > their latest api changes to this filesystem, it has not really moved > > forward into the "this is in shape to get out of staging" despite many > > half-completed attempts. > > I am happy to submit a patch that moves Lustre out of staging and into > the mainline. I'm just about to board a flight, but it could be done > later today. Then we can avoid the constant churn of kernel newbies > submitting patches that break the code. It's not the kernel newbies that are your biggest problem. It's your development model, and lack of support from anyone to actually do real cleanups. Every few months, when I get really bored, I do a drive-by pass and have never yet failed to find numerous problems that you all have been totally ignoring. Look at the debugfs patch series I sent out this week. Look at all of the wonderful work that NeilBrown has been doing on core cleanups for your mess. Neither he nor I should be the ones that have to do this stuff, you all should be doing it yourself. You all have had over 5 years to work on cleaning up your crazy shim layers. It's still not done. And based on the recent patch series that was sent to me, I don't even see anyone planning on working on that type of thing. I'm sorry, but I am tired of it. If you want to submit this for the filesystem maintainers to accept, wonderful, please do so. But that will not consist of a patch that just moves the directories. You have to create a real set of patches and send them to linux-fsdevel, just like any other new filesystem does. And I would like to point out the fact that while this whole thing sat in staging, other filesystems and major driver subsystems entered staging, got cleaned up, and moved on out. It can be done. But for some reason you all don't want to do the real work to do it, which is fine, I understand that you need management buy-in to make that happen, and you all need to focus on your users and new features for them. So if you really do want this out of staging, go off and do the real work to do so and then merge it the "real" way. I'm tired of dealing with it in staging as-is and having to every few months start rejecting new feature patches and tell people that "this is the last time I'm going to tell you..." You all were warned many times, this is not my fault, but rather, yours, or your management for not allowing you to prioritize this work. > Lustre has been in use at large sites around the world for 18 years now. > Over 70% of the largest 100 systems in the world use Lustre. It runs at > universities, oil companies, weather bureaus around the world, etc. And yet, I bet none of them run the in-kernel codebase, right? I bet you could get all of this cleaned up and merge properly in 6 months if you really wanted to do so. But it seems that no one really wants to do that work, which is sad. I should not have to be the one to force you all, but it seems like I now have to be. > I know Andrew has long been a supporter of getting code into the kernel > that users are using. This is code that thousands of large computers > are using with exabytes of storage, a lot more than orangefs, exofs, and > random other filesystems that seem to get into the kernel easily. Because those developers took the time and did it right. Please, compare yourself to orangefs. That is the perfect example of how to do everything right. They got their code into staging, cleaned it up, talked to us about what was needed to do to get the remaining bits in proper shape, they assigned dedicated developers to do that work, talked with all of us at different conferences around the world to check up and constantly ensure that they were doing the right thing, and most importantly, they asked for feedback and acted on it. In the end, their codebase is much smaller, works better, is in the "real" part of the kernel, and available to every Linux user out there. So yes, you are no orangefs, but you really should aspire to be just like them, as they know how to do all of this correctly. > It's true the code is not as pretty as it could be, but the same is true > of code that has been in the kernel for ages. If you know of major subsystems that look at bad as lustre does with the numerous wrapper layers and other crazy things that you all do, please let me know and I will be glad to go point people at that code to help get it fixed up. Also note that the attempt to defend your behavior with "but he's doing the same thing over there!" is not a valid defense at all. I'll gladly go over and deal with your misbehaving sibling after dealing with you :) > We've spent years cleaning it up in staging, and it has gotten a lot > better. Better yes. Correct and mergable out of staging, no. You all have had plenty of time to get your act together. Maybe this is what you all really need to kick it into gear to do it correctly. I certainly hope so, because I think we all can agree that what we have been doing for the past 5 years is NOT working at all. sorry, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
