5 ms·

> This is what's wrong with Linux kernel development. We have pluggable subsystems like I/O scheduling or CPU scheduling where BFQ or BFS are not mainlined and

> This is what's wrong with Linux kernel development. We have pluggable subsystems like I/O scheduling or CPU scheduling where BFQ or BFS are not mainlined and have to live as external patchsets. Then we have more than a few competing tracing/probing frameworks all somehow magically in torvalds/linux.git despite their overlap and unfinished (partly experimental) state. > I used to think that Linux kernel development is about who comes up with good, working code, but more and more I'm starting to get the impression it's that you need to have the right connections for a competing implementation to land. I think this is true of all sufficiently large organizations with human interactions: politics is an integral part of them. It also reminds me of Con Kolivas's reasons for no longer working on the mainline kernel: http://forum.digit.in/chit-chat/81361-why-i-quit-kernel-developer-con-kolivas.html http://forum.digit.in/chit-chat/81361-why-i-quit-kernel-deve.... Generally, I just hope that server developments and improvements trickle down to my personal computing devices.

pawadu 10y ago
Lets view this from another angle: you want to work in a project with tens of thousands of developers and literally billions of users. No matter your works technical merits, you simply cannot DEMAND that Linus accepts your huge patchset without having a very good track record. Con did not have that track record. In fact, he made it very very clear that he was not interested in a long-term commitment and that he was not willing to compromise. I am sure Con was a good programmer, but he was also a cowboy programmer with awful people skills. So this was never about "knowing the right people".
- cm3 10y ago
  Let's ignore BFS because my motivator for using a -ck kernel is the availability of BFQ. I mean, I didn't claim it's generally about knowing the right people, but some occasions, like the one mentioned above, do not leave much room for interpretation. BFQ in particular has been discussed years ago on LKML, and while the general design of it was deemed beneficial, the consensus from the kernel maintainers had been to refactor CFQ and turn it into BFQ. Given the pluggability of I/O schedulers, and already having at least three bundled schedulers, this makes no sense and is hard to explain to users of the kernel. Now years have passed and neither did CFQ evolve in the discussed way nor did BFQ enter torvalds tree. The argument I'm making is that in the meantime many unfinished and experimental bits landed in mainline. If I were the maintainer of a patch like BFQ, I might possibly take the effort to a more inclusive kernel, and integrate and refine it there after it's mainlined.

pawadu 10y ago

Lets view this from another angle: you want to work in a project with tens of thousands of developers and literally billions of users. No matter your works technical merits, you simply cannot DEMAND that Linus accepts your huge patchset without having a very good track record. Con did not have that track record. In fact, he made it very very clear that he was not interested in a long-term commitment and that he was not willing to compromise. I am sure Con was a good programmer, but he was also a cowboy programmer with awful people skills. So this was never about "knowing the right people".

cm3 10y ago
Let's ignore BFS because my motivator for using a -ck kernel is the availability of BFQ. I mean, I didn't claim it's generally about knowing the right people, but some occasions, like the one mentioned above, do not leave much room for interpretation. BFQ in particular has been discussed years ago on LKML, and while the general design of it was deemed beneficial, the consensus from the kernel maintainers had been to refactor CFQ and turn it into BFQ. Given the pluggability of I/O schedulers, and already having at least three bundled schedulers, this makes no sense and is hard to explain to users of the kernel. Now years have passed and neither did CFQ evolve in the discussed way nor did BFQ enter torvalds tree. The argument I'm making is that in the meantime many unfinished and experimental bits landed in mainline. If I were the maintainer of a patch like BFQ, I might possibly take the effort to a more inclusive kernel, and integrate and refine it there after it's mainlined.