Date: Tue, 5 Mar 2002 09:15:54 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: Julian Elischer <julian@elischer.org>, FreeBSD current users <current@FreeBSD.ORG>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, Bosko Milekic <bmilekic@unixdaemons.com>, Alfred Perlstein <alfred@FreeBSD.ORG>, Terry Lambert <tlambert2@mindspring.com>, Bruce Evans <bde@zeta.org.au> Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <200203051715.g25HFsk60359@apollo.backplane.com> References: <XFMail.020305105150.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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
<dillon@backplane.com>
:--
:
:John Baldwin <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203051715.g25HFsk60359>