Greg Woods wrote: > I am not a kernel developer, but I know a little about this indirectly. > Whether a project gets accepted into mainline depends on a lot of > things, but one of the big ones is how intrusive it is. If it requires > changes to many drivers and many places in the kernel, it is much more > difficult to get it merged into mainline. This is why, for instance, the > Xen hypervisor is still not part of the mainline even though it has been > used in production in many places for years (and is officially supported > in Red Hat Enterprise). Conversely, the KVM hypervisor is part of > mainline already, even though (in my experience) it is not nearly as > robust as Xen. But KVM is a much less intrusive set of patches so it was > much easier to get it merged. What you say is generally true, but in some cases there is a legitimate suspicion that being "in the right circles" plays a role too. You are right on Xen/KVM, but for example: - 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?] - 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 [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)] Tuxonice is just another of the big "but why not?" denied projects. In this way, real features are missed. I do not have a particular interest in "desktop oriented" scheduling, but I really care about efficiently storing 1 million 50-byte long files in a single dir (is any filesystem better than reiser3 for this?), and I really care about a reliable hibernation which saves everything (including the cache! cache *is* system speed, nowadays) to disk in compressed/encrypted form while pushing the maximum speed the HD is capable of. -- 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
