Kevin Kofler wrote: > Roberto Ragusa wrote: >> - a scheduler from Con Kolivas is developed for years and widely used, >> merging it is always denied until someone else creates a "similar" >> scheduler and it is accepted immediately >> >> [the scheduler is a core part of the kernel, so why a freshly written >> one is preferred to a mature one?] > > Because it was developed by Ingo Molnar, the maintainer of the scheduling > portion of the kernel. He knows what he's doing. He also provided a few > technical reasons of why his Completely Fair Scheduler is better than the > Con Kolivas staircase schedulers it was inspired by. I know that it was Ingo Molnar who wrote the CFS. Don't you think that being "the maintainer of the scheduling portion" is an exact definition of "being in the right circles"? I'm not saying that core developers have an easy way to merge low quality patches, just that "we know you" is a factor when a decision has to be made. I will not even say that this approach is wrong, I'm just saying that this is how things actually are done. Anyway, let me say that I remember performance regressions threads on the LKML when CFS was merged: Ingo promptly worked on those. And let me also cite that Ingo switched from "I don't like the approach" to "thanks to Kolivas for inspiring the idea". To many this sounded like a "I will keep fighting you for as long as enough to have my implementation ready". >> - the reiser4 filesystem has been released in 2004 (!) and has never >> been accepted; ext4, instead, has been basically developed inside >> the mainline kernel and a similar thing happens for btrfs > > Because reiser4 is designed in a way which the Linux kernel developers said > is unacceptable and the reiser4 developers refused to change it. It does too > much in the file system instead of letting the other layers of the Linux > file system stack handle things (kinda like ZFS, for which the relevant > Linux kernel maintainers said they'd reject it even if it were acceptably > licensed due to this "everything in the file system" design). IIRC an agreement was reached about avoiding the "plugin" stuff and the "files are dirs" stuff. There were other issues (in some cases purely stylistic, such as debug macros) and I remember there was a lot of cleanup work done on reiser4 to satisfy the requirements for a merging that never happened. The end result has been that a potentially good filesystem has been put aside for 6 years. And it is now obvious that it will never get merged. >> [a filesystem is something totally isolated, only people using it >> can have problems; the rejection was justified by saying that Hans >> Reiser is a difficult guy to cope with (which is probably true)] > > FYI, Hans Reiser is now in prison for having killed his ex-wife and unlikely > to ever get out of it. (They're serious when they say "life in prison" over > in California.) I know. This was included in my "which is probably true". I didn't want to bring Hans' personal problems in this discussion, especially as a form of respect for Nina's end. >> Tuxonice is just another of the big "but why not?" denied projects. > > There were concrete technical objections there too. I remember the criticism about the progress bar in VGA mode and the "why do you save the cache" (stupid) objection. But, even in this case, nobody really sat down and tried to discover what Tuxonice was doing better than the official suspend; there had to be something, if it works where the other doesn't, is faster at suspending/resuming, gives a fully functional system immediately after resuming... You can't deny that some projects are actively kept out of the kernel even if they could be included in experimental form for better refining and testing. Multiple schedulers? No. An extra filesystem? No. An extra suspend method? No. On the other end... open doors to ext4, btrfs, kvm, nouveaue, kms and I'm not sure how many memory allocators the kernel is now including (sl*b). My kernel contributions were never big, but I see there is indeed a contrast between "please, merge as early as possible" and "go away with this unfinished stuff". -- Roberto Ragusa mail at robertoragusa.it -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
