Matthew Dillon wrote:
>     My patches have been tested, they work, and they ARE going to
>     be committed as soon as I am able to do so.

        "Tut, tut, looks like rain!"
                        -- Winnie the Pooh; A. A. Milne

If you guys spent as much energy documenting your designs as
you do bitching at each other, everyone would now have a clear
idea of which side they should be on, or if there were even
sides to begin with -- since the worst thing John has said
about the patches is that they'd be a premature optimization
that he expects to be needed later, but inappropriate now.

>     There are already hacks in the trampoline/fork_exit
>     and ast code that seriously pollutes the MD/MI boundry, all of which
>     you've flicked off your shoulder and explained away as being allowed
>     by your API, and Peter added a third hack with his pmap commit (which
>     got backed-out when he backed out the commit).

Peter's pmap code was good work, but he ran head on into an
undocumented processor bug that FreeBSD had escaped earlier
by serendipity.  Remember the whole AMD/Intel/AGP discussion?

>     You have
>     so many balls in the air constructed in a fine mesh that you can't seem
>     to accept a single change to your perfectly meshing subsystems, half
>     of which are going stale in P4.  This is greatly restricting your
>     ability to consider deviation.

Whether deviation is called for or not is still an open
question, to my mind.  However, you have a point about the
uncommitted work.  On the other hand, it was you who have
been arguing so strenously that the size of the patches
that need to go in in one go make them "too dangerous".

And John has a point about the uncommitted work, in that
the SMP system doesn't make it to single user mode with the
preemption patches.

I think the right thing to do is to commit the cred changes,
and stabilize them, if there's even a problem, as you expect
from your comments about "dangerous".

I think the right thing to do on the cred front, *after*
that, is to commit the patches -- John, if it won't boot
to SMP afterward, you will have the eyes of everyone who
uses SMP -current to help you discover why, and to correct
the problems, which will happen *much faster* with a large
number of eyes on it.

>     I will repeat, if you want to discuss specific technical issues related
>     to these commits after I put them in, I am all ears.  I will repeat, I
>     see nothing in this code that prevents you from accomplishing anything
>     that you've brought up to date (which so far as just been the non-working
>     preemption code you have sitting in P4).

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to