On 8/3/07, T. J. Brumfield <[EMAIL PROTECTED]> wrote: > First off, I am an avid reader of the LKML but I'm not a developer. > Admittedly I am a piss-poor C developer who likes to poke around the > code, play with patches and attempt to learn, but in reality at best I > pretend I understand it, and I don't really. I fully defer to the > technical knowledge of far greater minds on this list. Even having a > basic understanding of C and looking at the code, I still don't > understand basic kernel operations like memory management or CPU > scheduling well enough to see in code what works best. > > What I can say, is that someone who has had years of project > management experience, it is painfully obvious here that there are > events here in personal issues which should be easy to spot and > rectify. > > I, like many people, had been using Con's patches for years and were > greatly pleased by them. I've experimented with a variety of kernel > flavor and patches, often woefully trying to amass my own collection > of custom patches and often breaking things while trying to integrate > too many patches at once that don't patch nicely with one another. > And when I've had questions, I often read through Con's mailing list > archives from his site. > > It would appear he spent 4 years working on his patch-set, primarily > based around his version of a scheduler. And in reading the LKML it > seems that aspects of his patch-set he pushed for mainline inclusion. > He was shot down saying that his ideas were flat-out wrong, and still > he worked for years to improve his work. He answered questions, fixed > bugs, and made himself very available. > > It may very well be that CFS is a better scheduler than SD. Ingo is a > very respected coder, and from even Con's mouth it seems that CFS is > pretty simple in its execution. Ingo seems to suggest that since he > posted his code so quickly after he wrote it, that he didn't do > anything wrong. > > Linus, a man I greatly admire and respect, especially for his > blunt/terse statements, also seems to suggest that no one has wronged > Con here. However in insisting that the decision was based on Con's > inability to support his code, I can fully understand why Con would > leave kernel development permanently. > > The simple truth is that Con poured years into a project despite being > rebuffed and told he was wrong. The moment that people change their > minds and realize that his concepts have merit, no one apologizes for > all the past criticism. Ingo did very much credit Con for > inspiration, but I can't see how this decision was anything but > political. Linus said it himself, that he trusts Ingo to stand behind > the code, and he didn't trust Con to do the same. > > I am reticent to accuse anyone of dishonesty, but that statement just > doesn't seem to add up. And even if that is the way Linus truly felt, > it doesn't seem fair given how well Con had supported his code and his > users. Regardless for a man who claims to not make political > decisions on code, that is exactly how he operated here. He chose the > person over the code. From his own mouth, it seemed he remains very > put off by earlier comments from the "Con camp" that perhaps there > should be separation between the server and desktop kernels. > > And while Linus is no-doubt correct that such a separation should not > occur, I never really saw Con push for such a thing. I know I don't > fully understand the code, but it does seem to make sense to an idiot > like me however that with all the other kernel options to customize > your build for your needs, it isn't beyond reason to go with a > plugsched type solution. The kernel is already immensely modular, no > doubt the most modular piece of code on the planet. > > It works amazingly well in small embedded devices to large > multi-processor servers across multiple architectures and processor > types. The reason I'm posting on an issue I'm sure that many people > are already sick of, is that I'm sure many people would like to see > two things happen. > > 1 - Can someone please explain why the kernel can be modular in every > other aspect, including offering a choice of IO schedulers, but not > kernel schedulers?
Good question. has been answered in other threads. Linus does'nt like having separate kernel schedulers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
