Date: Thu, 02 May 2002 18:42:06 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Peter Wemm <peter@wemm.org> Cc: Bill Fenner <fenner@research.att.com>, phk@critter.freebsd.dk, arch@FreeBSD.ORG Subject: Re: PHY patch, please test. (was Re: savcore dump names?) Message-ID: <3CD1EAEE.D3E8DC94@mindspring.com> References: <20020503003255.0C5213810@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
OK, this is a seperate thread... It probably belonged here, and not on -current, in the first place. Peter Wemm wrote: > Better check, he's about to gut functionality from miibus too. Since it > doesn't affect common cards, we are not likely to find out if or how badly > it breaks things until 5.x gets released. > > http://phk.freebsd.dk/patch/phy00.patch You commented on this already on the -current list: ] So, in a nutshell, you removed the ability for the card driver to request ] the phy driver to wait for negotiation to complete, and removed the ] interlock that prevents duplicate negotiation requests when the negotiation ] took longer than the allotted time? To which he replied "yes and yes". This question by you, and his response, sent up the red flags for me. I saw your initial objections to him committing the code (above), and I agreed with them. However, he made the point that there are a number of very long delays (500ms) which will occur at link-up time. I really agree with these being bogus, so if he can remove them, and is willing to do the work, it's a good thing. These are half second stalls ... enough to trigger an IP takeover by an IP redundancy protocol, which would be incredibly degenerate behaviour. He also made the point that: | There is no such thing as duplicate autoneg requests, if you send a | new one (like we do after the 5 or 10 sec timeout) the negotiation | starts over. I don't know if this point is valid, without further discussion' this fails to address his "shoulds"... the fact is that, "should" or not, until the drivers are fixed to be able to work that way, ripping out the working code is a bad idea. His: | And as you said yourself: there is additional NEWBUS'ing to be | done in this area. [ ... ] | Volounteers welcome. Was pretty omenous, in this context. (See? I basically agree with you.) BUT... you didn't respond to his response. You just let it sit there. This implied to me that he had satisfied you, and that if I had complained that it didn't satisfy me, I'd have both of you on my case about it. This posting is actually the first indication of your continued objection to the commit of the code, as far as I can see from the list archives and my -current inbox. It wasn't really clear to me whether or not he was proposing to implement the "much more capable state engine", as a response to your complaint, or whether he was leaving it as "an exercise for the student". Do you intend to respond to his posting, in context, on the -current list, or do you just intend to complain about the patches, using them as examples of "bad things Poul has done or intends to do"? If you want examples of "bad things Poul has done", IMO, well, I have a long list, and Julian has a long list, and I'm sure we can all complain about each other for a very long time. Personally, I would really *hate* for his miibus changes to go in without answering your objections, but leaving your objections hanging there with his reasponse going unanswered is just asking for them to be committed. He has some valid points, but I'm not sure that his approach of breaking it and letting people who care about it pick up the pieces will work. It certainly didn't when the X.25 and ISODE code was broken under similar circumstances by partial routing code changes, back in the mid 1990's. If this is a policy issue, then make it a policy issue, but it's going to have to result in a policy that applies equally to everyone. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CD1EAEE.D3E8DC94>