Date: Thu, 7 Mar 2002 10:20:20 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, 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: <200203071820.g27IKKq68196@apollo.backplane.com> References: <200203071538.g27FcKI56152@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> The API is intended for the stage-2 commit. The stage-1 commit
:> is intended to do all the 'hard stuff' in as straightforward
:> a manner as possible. The sysctl / option you talk about here
:> existed in my patch set 2 and a half weeks ago.
:
:The API and getting it right is more important than the "hard stuff".
:Its not as fun, but the API will outlive the code (consider the next
:arch, and the next). It may take more of your time due to discussion
:and feedback to get the API in place, but that's part of the cost of
:collaboration.
:...
:> I really wish you people would at least read the patch and commit
:> message before you comment on it.
:
:I didn't have to read the patch to know that there were concerns and
:on-going discussion about the API. In this instance, the issues are
:not large and can be remedied quickly - all the more reason for the
:discussion to take place before the commit.
Again, bullshit. You should have read the patch. How can you
possibly justify a lecture on what I should and should not be
doing when you don't even read to bother the material under
discussion?
:I didn't have to read the patch to know that you didn't seem to care
:about getting the API "right" before commiting the code. The API
Again, complete and utter bullshit. You actually believe that
because I want to commit this stuff in multiple stages and decided
that the API change would be in stage 2, that this somehow magically
means that "I don't seem to care"? How the hell did you come to
that conclusion? Did you even bother to read the commit message?
I'll tell you why I want to commit the stuff in multple stages...
BECAUSE THAT ALLOWS THE CORE OF THE CODE TO BE TESTED WHILE THE
REMAINING STUFF CAN BE DISCUSSED AND/OR WORKED ON. That's why.
I am not going to spend months integrating change after change into
a patchset, having to retest the whole mess every time, and then only
after months commit the final result. That is not how I work and I
strongly oppose that kind of methodology. I prefer to work in smaller
chunks and yet here you are trying to justify your nonsense by making
further attacks on my methodologies and code that are completely
absurd and completely unsupported by any evidence whatsoever.
This is complete and utter nonsense. You seem to believe you know
a lot about my motives without reading one goddamn line of code.
Because you know what? The commit message laid this all out in
very clear terms.
:I didn't have to read the patch to know that you would only remove your
:commit if someone could point to specific defects in the "hard part" of
:your submission. The "hard part", how it works, and whether it contained
:any bugs or not was not the real issue. This is why you and John were
:talking right past each other.
Excuse me, but I think whether something contains bugs or not is
a more serious issue then which source file the code winds up being
in.
And, again, you seem to be making ridiculous assumptions that are simply
not true. Change the API? I am doing no such thing. I am expanding
one portion of the existing API. The procedural interface has not
changed. The procedure names have not changed. The location of the
procedures change, and the capabilities of the procedures have changed,
and certain restrictive assumptions regarding hard interrupt
disablement have been changed.
But you, and others, do not appear to be willing to face up to the code or
its straightforward intent. Intead you are reading all sorts of garbage
into its meaning, WITHOUT EVEN BOTHERING TO READ IT.
It is unbelievable to me that a professional such as yourself would stoop
to such tactics without backing it up with one shred of evidence and not
even having bothered to read the code in question. And instead of
standing up and apologizing for that, you instead feel that you have
to start making wild accusations without one single hard reference
to ANYTHING I have done.
:..
:you can colloborate and coordinate with others in this project. The only
:issue is how that colloboration takes place, and the *process* for getting
:things done. If the process makes it twice as hard for us to get things
:done, then it's broken. In that case, *attack the process*, not the person.
:The process can and will change but only if we set aside "personal
:indignity" (why should I have to put up with this crap!?!?) and attack
:our problems and goals as engineers.
Hey, I'm the one being attacked here. This whole mess started with
people attacking me. If people had let well enough alone.. if people
had simply read the goddamn patch rather then attack its intent (if
you even know what it's intent is since so far you are batting 0 on
that front), then we would not be in this situation.
Instead it's attacked because it is perceived as 'Matt tromping all
over John's stuff'. Except there is no 'stuff' to tromp over. Not
a single person has shown how my stuff tromps over anything, not John,
not you. So why the fuck do you feel justified to attack this commit?
There is no tromping going on except in the minds of a few people who
believe that John should be consulted about every last thing that
goes into the tree, and they don't care if John takes three fucking
weeks to respond.
I don't understand why you and others believe that this patch is such
a huge deal. It just isn't. It does not make any major changes to
the API. It just moves things around and gives the critical*()
code a few more features that allows architectures to optimize them
a bit better, uses the new flexibility to implement a better backend
for I386, and fixes a couple of nasty bugs to boot. It's important to
me but I don't see how it could possibly have any adverse effect on
the project and, frankly, I don't see why anyone, especially John,
would be opposed to it (I don't even think he bothered to read the
patch).
-Matt
Matthew Dillon
<dillon@backplane.com>
:Sometimes the flare-ups in FreeBSD remind me of the middle-east. Each
:side accuses the other side of "starting it", or "having the blame". In
:reality, both sides were jerks, own portions of the blame, and have
:concentrated on continuing the conflagration rather than mitigating it.
:I hope we have a better perspective on reality.
:
:--
:Justin
:
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?200203071820.g27IKKq68196>