Re: panic: APIC: Previous IPI is stuck

: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_at_{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