why 4.X instead of 5.X

[Chuck Robey]

On Thu, 17 Jul 2003, Matthew Dillon wrote:

>
> :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 at 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.

There is not a misread, but maybe I could have phrased it better.  The
question I asked was why branch off 4.x instead of 5.x, not whether spls
were a good thing, which we all agree must be gotten rid of.  I assumed
from the beginning that you would use mutexes, and having to redo all that
huge amount of work, when so much has been done in 5.1, well, that's my
question.

It just seems to me that we could get to where you want us to go faster if
we jumped off 5.1 than if we jumped off 4.8.

Is it because of the larger commit rate on 5.1 (harder to track), as has
been suggested?  Is it something intrinsically wrong that you don;t like
about the 5.1 codebase?

A lot of your suggestions below sound a lot like 5.1's work, don't they?

>
>     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
>
>

----------------------------------------------------------------------------
Chuck Robey         | Interests include C & Java programming, FreeBSD,
chuckr at xxxxxxxxxx   | electronics, communications, and SF/Fantasy.

New Year's Resolution:  I will not sphroxify gullible people into looking up
fictitious words in the dictionary.
----------------------------------------------------------------------------