Re: why 4.X instead of 5.X

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:I'm asking the same question I just asked on the FreeBSD-current list,
:this is a better place for it.  I really like the idea that FreeBSD has
:gone to mutex exclusion, and away from spls.  It was a huge, and hugely
:difficult task, and I don't really agree (yet) that we should throw that
:part away.
:
:Understand, I'm not saying you're wrong, I'm saying that I'm skeptical,
:and I'd really appreciate it if you'd take the time and explain why all
:that work has to be sacrificed.  I just feel that mutexes == good thing.
:
:----------------------------------------------------------------------------
:Chuck Robey         | Interests include C & Java programming, FreeBSD,
:chuckr@xxxxxxxxxx   | electronics, communications, and SF/Fantasy.

    Is there a misread somewhere?  I definitely intend to do away with SPLs.
    We can't get rid of the MP lock without getting rid of SPLs.

    My plan for SPLs is that as soon as DEV is converted to message-passing
    (each DEV being in its own thread), then any given interrupt needs to
    interact with only a single thread (well, not counting the issue of
    shared interrupts).  At that point a token or a mutex can be
    used to interlock the DEV thread and the interrupt routine and SPL 
    becomes irrelevant for that interrupt.

    We slog through all the DEVs and SPLs that way until we are left with
    just the hardclock() and statclock(), and those we lockout with a
    critical section.

    At the moment critical sections are being used as a poor-man's substitute
    for SPL inheritance.  DragonFly will likely have fairly significant
    interrupt latency issues for a long time because of that... until we
    can clean up SPLs and DEV interaction for good, in fact!  Interrupt
    latency is not something we should be worrying about at the moment,
    what is important is to ensure that the kernel remains a stable 
    development platform through the next 12 months.  My feeling is that
    it will be far easier to solve interrupt latency issues 12 months from
    now then to try to solve them now.

						-Matt