Date: Sun, 18 Jul 2004 14:09:09 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Matthias Buelow <mkb@mukappabeta.de>, Scott Long <scottl@samsco.org> Cc: current@freebsd.org Subject: Re: panic: APIC: Previous IPI is stuck Message-ID: <200407182109.i6IL99Ea010033@apollo.backplane.com> References: <FE045D4D9F7AED4CBFF1B3B813C85337051D936E@mail.sandvine.com> <200407180146.i6I1kiQ9004838@apollo.backplane.com> <40F9E518.9050800@mukappabeta.de>
next in thread | previous in thread | raw e-mail | index | archive | help
:Scott Long wrote:
:
:> The 'fix the bugs' discussions are going on too. However, this is the
:> freebsd-current list, and it's always nice to discuss things that might
:> be suitable further down the road.
:
:Yes, I might have gotten this wrong, I thought he was talking
:specifically about 5.x (which to me, and I guess many other users, means
:the long awaited stabilization of the 5.x tree).
:
:--
: Matthias Buelow; mkb@{mukappabeta,informatik.uni-wuerzburg}.de
I am using "-current" and "5.x" interchangably, since there isn't really
much of a distinction between the two, at least not from my point of
view.
As far as stabilization goes... well, the problem is that you can only
stabilize what you have once you have it. The APIs, abstractions, and
requirements are so complex in -current/5.x that every time someone
codes up something new, major bugs are introduced. Even worse, many of
the bugs introduced are difficult to reproduce, track down, and fix. Of
course, new bugs are introduced occurs with any OS development... DragonFly
is no exception. But there are 'normal occurances' of such things, and
then you have the 'its so fragging complex that I couldn't code it right
the first time if I tried!'. -current/5.x is definitely in the latter
category.
The question you have to ask yourself is: Do you want to spend all your
time tracking down all the bugs that are constantly being introduced into
the codebase, or do you want to simplify your APIs and abstractions to
*reduce* the instances of new bugs being introduced so you can spend more
of your time implementing neat new things instead?
Another question you have to ask yourself is: If you have a kernel whos
APIs and abstractions are so complex that even veteran kernel hackers
are having to test in perforce for weeks, months, or even longer before
daring to bring the code into CVS, and even then wind up with serious bugs,
what do you think the situation is going to be for all the other developers
out there trying to work on the FreeBSD kernel?
I'm not going to repeat all the suggestions I've made in the past. It is
obvious to me that FreeBSD development needs to stop *right* *now*, take
a step back, and figure out how to simplify the MP requirements for
all the major subsystems... then spend 3 months doing it. IPIs are a good
example... it needs a complete rewrite. The scheduler pretty much needs
a complete rewrite. The memory subsystem is in pretty good shape but
would work even better using a DragonFly style cpu localization model.
The interrupt subsystem... well, again, you need DFly style preemption
instead of heavy-weight-scheduler-integrated-with-priority-borrowing-
preemptive-thread-switching-and-preemptive-cpu-migrative-and-oh-yah-don't-
forget-to-pin-the-cpu-because-if-you-do-we-will-never-find-the-bugs-
you-introduce-otherwise style preemption.
-Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200407182109.i6IL99Ea010033>