How do you make these huge changes and stay so stable?
dillon at apollo.backplane.com
Tue Dec 21 12:31:27 PST 2004
:I'm reading the diary, as well as the roadmap for the KVA/page
:requirements/requests and I'm wondering how the heck you can rip so much out
:and replace it with so much new code, and still stay 'production stable'?
:It's pretty amazing. Do you guys just keep the patches to yourselves for a
:while to test them, or what?
Well, I don't think my own personal track record is *that* good. But it
is certainly a whole lot better then e.g. what we are seeing out of
the FreeBSD developer base. I've introduced plenty of bugs, as have other
DFly developers. The difference is that we are very focused on fixing
the problems that crop up as priority #1... and doing it right, not just
adding hacks to work around problems. So there are usually only a small
number of 'serious' bugs outstanding at any given moment. We are very
focused on producing maintainable APIs for subsystems... that is one of
my biggest requirements for new code. The result is a far more
maintainable code base then e.g. FreeBSD has. And I wouldn't be saying
that if I didn't think the evidence to the fact was incontroversial.
I would hold up Jeff's SACK implementation as the poster-child here.
Only three people really tested his code pre-commit, yet post-commit there
was exactly *ONE* (and only one) serious bug exposed to our user base.
And it was fixed very quickly.
Regardless of how the performance numbers turn out when we finally turn
off Giant (and I still believe that we are going to blow away the
competition in that regard), our threaded-subsystem model has reaped
us *HUGE* rewards with regards to code development, stability, and
<dillon at xxxxxxxxxxxxx>
More information about the Kernel