* Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote: > On 12/22/2009 10:01 AM, Bartlomiej Zolnierkiewicz wrote: > >>new e1000 driver is more superior in architecture and do the required > >>work to make the new e1000 driver a full replacement for the old one. > >Right, like everyone actually does things this way.. > > > >I wonder why do we have OSS, old Firewire and IDE stacks still around then? > > And it's always a source of pain, isn't it. Even putting aside the fact that such overlap sucks and is a pain to users (and that 98% of driver and subsystem version transitions are done completely seemlessly to users - the examples that were cited were the odd ones out of 150K commits in the past 4 years, 149K+ of which are seemless), the comparison does not even apply really. e1000, OSS, old Firewire and IDE are hardware stacks, where hardware is a not fully understood externality, with its inevitable set of compatibility voes. There's often situations where one piece of hardware still works better with the old driver, for some odd (or not so odd) reason. Also, note that the 'new' hw drivers are generally intended and are maintained as clear replacements for the old ones, and do so with minimal ABI changes - or preferably with no ABI changes at all. Most driver developers just switch from old to new and the old bits are left around and are phased out. We phased out old OSS recently. That is a very different situation from the AlacrityVM patches, which: - Are a pure software concept and any compatibility mismatch is self-inflicted. The patches are in fact breaking the ABI to KVM intentionally (for better or worse). - Gregory claims that the AlacricityVM patches are not a replacement for KVM. I.e. there's no intention to phase out any 'old stuff' and it splits the pool of driver developers. i.e. it has all the makings of a stupid, avoidable, permanent fork. The thing is, if AlacricityVM is better, and KVM developers are not willing to fix their stuff, replace KVM with it. It's a bit as if someone found a performance problem with sys_open() and came up with sys_open_v2() and claimed that he wants to work with the VFS developers while not really doing so but advances sys_open_v2() all the time. Do we allow sys_open_v2() upstream, in the name of openness and diversity, letting some apps use that syscall while other apps still use sys_open()? Or do we say "enough is enough of this stupidity, come up with some strong reasons to replace sys_open, and if so, replace the thing and be done with the pain!". Overlap and forking can still be done in special circumstances, when a project splits and a hostile fork is inevitable due to prolongued and irreconcilable differences between the parties and if there's no strong technical advantage on either side. I havent seen evidence of this yet though: Gregory claims that he wants to 'work with the community' and the KVM guys seem to agree violently that performance can be improved - and are doing so (and are asking Gregory to take part in that effort). The main difference is that Gregory claims that improved performance is not possible within the existing KVM framework, while the KVM developers disagree. The good news is that this is a hard, testable fact. I think we should try _much_ harder before giving up and forking the ABI of a healthy project and intentionally inflicting pain on our users. And, at minimum, such kinds of things _have to_ be pointed out in pull requests, because it's like utterly important. In fact i couldnt list any more important thing to point out in a pull request. Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
