Date: Thu, 28 Feb 2002 19:09:13 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Bruce Evans <bde@zeta.org.au>, Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <alfred@FreeBSD.org>, Bosko Milekic <bmilekic@unixdaemons.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, FreeBSD current users <current@FreeBSD.org>, Julian Elischer <julian@elischer.org> Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <200203010309.g2139DI40526@apollo.backplane.com> References: <XFMail.020228203314.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: : :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 <jhb@FreeBSD.org> <>< 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 <dillon@backplane.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203010309.g2139DI40526>