On Mon, Jan 28, 2002 at 04:28:57PM -0500, John Franklin wrote: > I don't think there is any wisdom to it. He tried to put new code into > a release-line kernel and got burned. It's taken them from 2.4.10 > to 2.4.17 to get things stable again.
Pardon, but that's slightly misleading. From the stable point of view, .11 and .15 are both unusable, so that's 6 revisions (.10, .12-.14, .16-.17). Rik's vm (which I _still_ think is superior though perhaps not as well-tuned) took 9 revisions. On top of that, Linus only merged the portions that he felt needed merging. From both Andrea's and Rik's words, bits were munged. Not exactly what one would want with such a major subsystem. Hardly an apples-vs.-apples comparison, however. The matrix of subsystems that changed in each revision is much too large to carry out an objective independent benchmark. In essence, it _is_ "what works, works." > That said, the new memory code is an improvement and 2.4 will benefit > from it. But it was still a bad software engineering decision to drop > it into release code. 2.4.17 is vastly superior to 2.4.10, agreed. However, by 2.4.9 Linus had pretty much wrecked Rik's vm (no offense, Linus). Given Linus's track record of only merging bits he feels "fit," the only sensible decision was to rip out the entire subsystem and "start anew." What 2.4.10+ gained was a much simpler (algorithmically, among other things) "general-case" vm. In the long run, this is much better than practicing "good" software engineering by dragging out the mess that unfortunately used to resemble Rik's vm. I suggest people who are interested in the nuts and bolts take a look at rmap. http://www.surriel.com/patches/ -- Dan Chen [EMAIL PROTECTED] GPG key: www.unc.edu/~crimsun/pubkey.gpg.asc
msg01029/pgp00000.pgp
Description: PGP signature
