Date: Tue, 28 Sep 1999 01:38:42 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: jkh@zippy.cdrom.com (Jordan K. Hubbard) Cc: current@freebsd.org Subject: Re: Loss of Functionality with newpnp Message-ID: <199909280838.BAA14314@gndrsh.dnsmgr.net> In-Reply-To: <20258.938459658@localhost> from "Jordan K. Hubbard" at "Sep 27, 1999 12:14:18 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
[Reinsertion of original answer by jkh] > > > That work is underway, and something to understand about -current > > > is that it doesn't have to actually work at all times during the > > > interim periods between releases. Now, should 4.0 be on the horizon > > > and the situation still be one where "equivalent functionality" > > > has not been provided by the newpcm driver, we'll revert back to > > > the original luigi driver and continue the experiment in the new > > > post-branch (5.0) current. [end reinsertion] > > If that was only true. Or should I ask why didn't CAM from -3.3 get > > reverted to the old scsi code before 3.3 was released. I have seen > > no less than 2, and perhaps 3 people try to get cards that did work > > under pre-CAM 3.x working under post-CAM 3.x. I know this is a slippery > > slope, but it invalidates your above assertion that we revert back > > at release when functionality has been lost due to new code. > > No, it doesn't invalidate it in any way shape or form. I said that in > this specific case, and you're free to read my message as many times > as you wish but you'll not find anything saying I was speaking for > anything BUT the newpcm driver here, the new stuff would be reverted > if need be. By implication the first sentence of your response seems to indicate that only between releases should functionality be lost. I'll agree that you only specifically sited the newpcm driver. > CAM was a rather different situation since it was one of > those painful-but-necessary trade-offs we had to accept both the pros > and the cons for. The a.out -> ELF transition was painful too, and > I'm sure there were a few ports which broke and/or older commercial > software packages which became harder to use as a result, but you > won't hear anyone talking about going back to a.out for just that > reason. > > Each situation is different and there are NO hard-and-fast rules about > when it does and does not make sense to accept the loss of certain > functionality in exchange for new functionality. To even assume > that such a rule would be practical would be like saying that life > itself always fits into neat, well-compartmentalized little boxes. :) And I won't disagree here either, but I will re-phrase, once FreeBSD has made the decision to go forward, with the understanding that some functionality is being lost, it has never made the step backwards. Which, IMHO, is _good_. But saying FreeBSD would step backwards if newpcm was missing ``equivalent functionality'' at 4.0, again IMHO, is an overstatement. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net 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?199909280838.BAA14314>