:
:
:On 28-Feb-02 Matthew Dillon wrote:
:> Not to put too fine a point on it, but, I don't see how this can
:> possibly justify preventing me from committing my critical_*() stuff.
:> You've just stated publically that your preemption stuff is unusable
:> as it currently stands. Why am I supposed to wait an arbitrary period
:> of time for you to fix, test, and commit it?
:>
:> I would REALLY like to commit my critical_*() stuff, and for the record
:> this will also include the stage-2 stuff described in the original commit
:> comments that will be made a few days after the current commit.
:
:Because the critical_* changes you are doing don't match up to the overall
:design. See my mail to -arch for more on that though. At some point in the
:future I think that this work can fit in rather well to the cpu_critical_foo
:stuff (which can be split out from critical_enter/exit now). However, at this
:stage I would rather avoid complex optimizations of APIs that may change in the
:future. There is more to be gained from locking subsystems.
:...
:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
:"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
I strongly disagree. I have yet to see any technical description of
this so-called overall design that shows any incompatibility, and what
I decide to do with my time is my business. I don't really care
whether you are ready for 'optimizations' or not. I seem to recall
that you had similar objections when I started pushing Giant into the
system calls, yet that work is in hind sight an obvious enabler for
other work people have been doing and committing.
I decided to address a serious issue that I've had with those routines
for months because you consistently refused to even entertain the
notion that you may have constructed the API wrong. Frankly, I feel
that these changes both optimize and properly abstract the critical_*()
code. I strongly believe that the abstraction you have in there now is
improper. My patches have been tested, they work, and they ARE going to
be committed as soon as I am able to do so. I believe you are
overstepping your bounds as a committer by attempting to scrap them
and I also believe that you do not fully understand the implications
of the code, because you are blinded by the notion that I am making
adjustments to your API. But I do, BDE does, Julian does, as do others.
To me these changes are essential, and they must go in now before
even more hacks are committed to the codebase to get around existing
limitations. 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). These hacks make it
crystal clear to me that you critical_*()/cpu_critical*() API is
seriously flawed. I am addressing the issue and cleaning up the hacks
to create a proper MD/MI separation of the code.
It makes no sense whatsoever to me to be told not to commit something
due to stale code that may not be quite compatible sitting in P4 that
you can't make work in any reasonable time frame. You should stop
trying to screw over my work and instead look to your own. 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.
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).
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
