BFQ I/O Scheduler Patches Revised, Aiming To Be Extra Scheduler In The Kernel

[Guest]

Which is why I smile when I read naive propaganda that in open source you can improve the code and share it upstream and everyone will benefit and bla-bla-bla, in reality there are gatekeepers upstream that will not let you do a big/serious contribution unless you're willing to go a very long way, and if you're doing it for free, 90% of the people will give up along the way, not to mention often you have to sign certain documents even for open source projects and learn their development and source code tracking stacks. So you might end up spending 5% of effort on creating the change and 95% on trying to get it included upstream.

It's you that spreads stupid propaganda. Let's say you're a maintainer of some project. If someone sends you a patch will you accept or reject it? It's up to you. If you reject he can always fork your project. I don't know who told you kernel maintainers are obligated to accept every piece of code somebody sends to them. Don't listen to stupid people. It's my advise for you. Linus and Co. shape Linux the way they want not the way you want. Summing up your objections against Open Source don't hold, naive one.

[jwilliams]

i think that is because linux is pretty much business critical at this point. even if businesses are rather conservative with upgrades.

also, if one would be so inclined they might just roll their own linux repository. which, thanks to the nature of git is exactly what many people do. people follow linus partly for traditional reasons, partly for him being the last line of sanity when something dubious gets past the maintainers.

you can definitely do so in smaller projects where things are easier to test, and impact is less critical. i managed to get a couple of things patched in fusioninventory, for instance.

That does not apply to this situation. The linux kernel has had a modular architecture for IO schedulers for years. Adding BFQ as another optional IO scheduler -- which a good project manager would have done years ago shortly after the BFQ patches were submitted -- does not affect overall kernel stability or any business critical applications. BFQ was repeatedly denied and jerked around for no good reason.

[cj.wijtmans]

That does not apply to this situation. The linux kernel has had a modular architecture for IO schedulers for years. Adding BFQ as another optional IO scheduler -- which a good project manager would have done years ago shortly after the BFQ patches were submitted -- does not affect overall kernel stability or any business critical applications. BFQ was repeatedly denied and jerked around for no good reason.

business critical: use LTS version of whatever software. no problem with merging BFQ even if it could make problems it wont affect business at all.

[johnp117]

at last, BFQ may be about to land into mainline