From owner-freebsd-current Tue Mar 5 9:16: 1 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id A3F4E37B400; Tue, 5 Mar 2002 09:15:55 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g25HFsk60359; Tue, 5 Mar 2002 09:15:54 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Mar 2002 09:15:54 -0800 (PST) From: Matthew Dillon Message-Id: <200203051715.g25HFsk60359@apollo.backplane.com> To: John Baldwin Cc: Julian Elischer , FreeBSD current users , Seigo Tanimura , Bosko Milekic , Alfred Perlstein , Terry Lambert , Bruce Evans Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> 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. : :*sigh* The only reason I'm not spending my cycles tracking down the preemption :bugs so that preemption can go in is that I have decided that at the moment :there is more gain to be found by doing actual locking work. This means that :preemption will eventually go in, just Not Right Now. To that extent, I don't :think premature optimizations based on observations of a kernel locked entirely :by Giant that alter the API's preemption will change (and that were originally :introduced when I committed all the bits of the preemption code that I could :w/o breaking the kernel) should go in. Those are your cycles, not mine. Why should I be forced to sit on my heals for an unknown period of time (but so far 3 weeks waiting for the ucred changes and 2 weeks waiting for critical_*()), twiddling my thumbs wasting MY cycles just because of your own scheduling issues? That's really the crux of this whole situation. I don't think it is appropriate for you to impose your development methodology on me or anyone else, and I most especially do not think it is appropriate for you to arbitrarily hold off the hard work that I have done in order to fit it into your schedule. I have said very clearly what I intend these critical_*() patches to do. I have said, repeatedly, that I do not believe they would intefere with your work in any significant manner. You have yet to explain in any detail why you think they would. I have said, repeatedly, that I am perfectly willing to work with you later on when you ARE ready to move forward on your own work. That's the crux of the situation, John. I do not believe you have the right to hold this work off, at least not based on any of the explanations you have given so far. -Matt Matthew Dillon :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ :"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-current" in the body of the message : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message