From owner-freebsd-current Thu Mar 7 12: 4:13 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 4864C37B402; Thu, 7 Mar 2002 12:03:57 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g27K3M368992; Thu, 7 Mar 2002 12:03:22 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Mar 2002 12:03:22 -0800 (PST) From: Matthew Dillon Message-Id: <200203072003.g27K3M368992@apollo.backplane.com> To: "Justin T. Gibbs" Cc: Matthew Dillon , John Baldwin , Bruce Evans , Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , FreeBSD current users , Julian Elischer Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem References: <200203071923.g27JN6I60361@aslan.scsiguy.com> 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 : :You came to the conclusion that only *your decision* on what was :an appropriate proceedure was the one that mattered. That's not :the way this project works. You can't act unilaterally. When people :ask you to hold off (and they even asked politely!) so discussion :can take place, that is not the time to commit. I did no such thing. I came to the conclusion because not a single goddamn person bothered to read the patch and instead the only argument I got was "wait for John" and John's only argument is "I don't like the idea of optimizing this routine right now" as if he would be the only one responsible for dealing with the consequences. I'm sorry, but simply not liking the idea of someone else doing a particular optimization now verses later is not a good enough reason to require that 40+ hours worth of work be thrown away when that other person has stated, repeatedly, that he will support said code. So far not one person, not even you, has been able to explain why the patch should not go in. John's only excuse is that he doesn't like the idea of optimizing it now. John has stated on several occassions that he believes I am breaking future work (like preemption). I have responded every time by asking him to clarify exactly what he thought would be broken. He has consistently refused to clarify his statement. I have read his tiny little 10-page SMP document and there is absolutely nothing in that document which is at odds with my patch. Not one thing. I am angry because you and a number of others are not willing to take the work at face value and instead insist on making ridiculous extremist assumption into it and then using that opinion to justify not allowing the patch to go in. I have said, REPEATEDLY, but you can't seem to understand, that I am totally open to making adjustments to the code. I am not willing to throw it away, but I am willing to make adjustments to the code. I don't see why the patch should be held up. But you know something? You and others don't seem to be interested in having a conversation about possible improvements. You seem to be out for blood, to prevent the patch from going in at all costs no matter how good it is, without even having bothered to read or understand it, and that makes me unbelievably angry, I don't see how you can possibly tell me that I am not being a team player when I am being told to throw the code away completely. I think it's John who is not being the team player here, and others, who seem to believe that me throwing the code away is the correct solution to their ills. :> 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. : :One week of discussion will not prevent the code from being tested. Coming on THREE weeks now. Three weeks of my time wasted arguing with people who don't even bother to take the time to understand what I am trying to accomplish, who seem to regard a relatively straightforward patch as somehow being an attack on John's leadership when that could not be farther from the truth, who seem inclined to do nothing but bash me personally and supply opinions without one shred of evidence to back them up. I can't fight your opinion of me, but you can't expect me to listen to you if you can't justify it. You have already shown very clearly that you aren't even interested in looking at the code, that you don't care what it does, but you are against it anyway. You response is to ignore the points I have brought up and then start bashing me personally. :> 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. : :I've counted weeks so far and those weeks weren't even necessary. Now :your expecting months and years of delay? Please. Gee, lets see... why don't YOU ask JOHN how long he intends to wait before he allows this sort of optimization to be made? Eh? Please. : :> That is not how I work and I strongly oppose that kind of methodology. : :I think you've made that clear already. The question is whether you :are willing to compromise so you can be part of a team or not. That :means, for all of us, that we will not necessarily be able to work in :the way we would personally want, all of the time. That's what happens :in a group environment. That's life. This is not about being part of a team. You don't have to be forced into using someone else's methodology to be part of a team. Being part of a team means respecting other people's metholodogies and it means compromising. There has been no compromising here... John has made it clear that he doesn't want any work whatsoever to be done on the critical*() code. I can't even get THE FIRST GODDAMN STAGE OF MY PATCH IN. This IS about team work, but you are barking up the wrong tree if you think I'm the one who's not being a team player here. There is plenty of room for discussion. But discussion != Veto. It isn't a discussion when all you try to do is prevent code from being committed to the tree. I have said REPEATEDLY that I am willing to adjust the code based on a discussion. But I feel, strongly, that the Stage-1 code is ready to go in now so a widier audience can test it. I do not believe it is appropriate to simply veto it. I HAVE NEVER SAID THAT THE CODE COULD NOT BE CHANGED. Hello? Are you even listening to what I am saying? I do not feel that weeks of discussion are necessary before the first commit, but that does not imply in any way shape or form that the first commit somehow sets things in stone. :> 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 not an attack on any such thing. This is about *process*. You :want to commit in small chucks? Great! You want to get this stuff into :the tree quickly? Great! You want to make the code so it can be dynamically :configured for testability? Great! You don't want to discuss API changes :that have affects on other ports, and other subsystems prior to committing :them? That's unacceptable when people are asking you to explain them first, :regardless of how well thought out or implemented they are. This is not a :race to commit. This is about developing a well designed system without :killing each other in the process. Say what? Who said anything about me not wanting to discuss API changes? That's all I've been TRYING to do for the last three fucking weeks! Are you discussing API changes? No, you are basically just bashing me. That's all that you people have been doing for three fucking weeks. Not a single one of you has discussed WORD ONE about the API. Instead of harraunging on me about not discussing the API, maybe you should consider discussing the API. I haven't even changed the goddamn API yet! The stage-1 patch isn't about the API, it's about proving that we can leave interrupts enabled, and it's about fixing bugs. :For this kind of change, the commit message should have been the last, :not the first "public forum" to have expressed these ideas. : :>: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. : :Did I say anything about source files? This is about discussion prior :to commit. Nothing more. So far there has been no discussion. Not a single person, most especially john, has attempted to initiate any constructive discussion about the API. :> 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. : :How is expanding an API not a change to that API? Why is it that when :other developers express a need to discuss these changes prior to them :being committed, their concerns don't matter to you? Are you the only :person in the project that can't keep changes in your local tree for :a few days while you present your ideas? Do you even know the change I am making? The other developers so far don't seem to be interested in talking about the actual CHANGE I made to the API. The only discussion about the API changes were made by me and BDE. Everyone else seems intent on bashing me and bashing the patch but do not seem to be interested in having a discussion about what the patch accomplishes. :> 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. : :I have done no such thing. The facts are very simple: : :Matt: I'm going to commit this code to the tree :Others: We should discuss the rammifications first. :Matt: We can discuss it after its in. :Others: No, we need to discuss it first. :Matt: Commit :Others: Back it out until we discuss it. :Matt: !@#$%^$@#. Every time I try to do something its blocked.... : :The content of the changes simply don't matter. You obviously didn't go back far enough. These are the facts: Matt: I'm having a go at fixing critical_enter (Matt discusses what he would like to do). Bruce: Say, I did something very similar to that. Matt: Really? Why didn't you commit it? Could I have a copy of what you did? Bruce: I hacked a bunch of the issues and it is mixed in with other things. Here's a diff of my sys tree. Matt: Wow! Great stuff. (Matt goes off into a corner and does his stuff, using BDE's code). Matt: Ok guys, I think I have something that works, here try this. (two days pass, a few people respond positively) Matt: Ok, I am going to commit this. Others: wait a week for John. Matt: huh? I don't think this interferes with anything john is doing. Others: wait a week for John. And it went forward from there. My ucred changes were already on hold, and now I was faced with waiting a week for a John. Well, after all of that I finally got tired of waiting. I said, very clearly, that (A) I intended to commit it. That (B) I had no problem discussing issues with the (unresponsive apparently on vacation) John after the commit And from there it blew up into the mess you see today. So, you see, I didn't "just commit it out of nowhere". I waited what I believed to be a reasonable period of time. I have two other stages waiting in the wings, and, yes, I don't think it's appropriate for one person to be able to arbitrarily hold up dozens of hours of work for an arbitrary period of time, especially when that person (me) is perfectly willing to make changes to the code in later commits. Now who is being unreasonable? Why do you believe that it is absolutely necessary that I be prevented from committing the work? :> 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. : :The evidence is in the lists, not the code. And so is mine. :> Hey, I'm the one being attacked here. : :No. There was nothing personal in Robert Watson's request for you to :wait. He would have said it to anyone in the same position. I don't :know why you took it as an attack. Robert was just trying to place some :proceedure (just as he did at the devcon) on what has been a very :chaotic process. If someone asked me to wait a day, or even two, it would not be a problem. But if someone asks me to sit on my heals for a week, or two, or THREE, without any direct justification, then, yes, I consider it to be an inappropriate request. :... :It is only a huge deal because it was made into a huge deal. If the :change had been discussed prior to being pushed into the tree, this :would never have happened. I don't think that John, or anyone else, is :opposed to the change going in once some small issues are discussed first. :Just get over this "I've been abused" bit already and discuss the changes! :We all want to move on and I'd rather see us moving on with your changes :than without. : :-- :Justin It's only a huge deal here because you people have turned it into one. This patch has no adverse effect on anything that ANYONE is doing, including John, and yet you and John and a few others seem unwilling to even consider it on the grounds that it somehow interferes with John's perfect plan for the futuer of SMPng. I do not believe it interferes with his plans at all and I have repeatedly asked you and others to supply hard facts as to why you believe it does. Not a single person has been able to supply a single fact showing how it interferes so significantly with any other work that it must not go in at any cost, and that really pisses the hell out of me. I will repeat: This is a damn good patch. I want to see it go in. I am willing to discuss the API changes. I do not believe it is appropriate to simply veto all the hard work I have done here without supplying a single hard reason as to why, and that is what you people are doing. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message