Date: Thu, 23 Apr 1998 14:42:05 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Nate Williams <nate@mt.sri.com> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, shimon@simon-shapiro.org, current@FreeBSD.ORG Subject: Re: A CAM of worms Message-ID: <199804232045.OAA11155@pluto.plutotech.com> In-Reply-To: Your message of "Thu, 23 Apr 1998 14:18:51 MDT." <199804232018.OAA11026@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> There is certainly a migration path. Run a CAM kernel or don't. Must >> developers I know have plenty of space to store two sys trees. As I >> have stated to Julian several times, I will not polute the CAM code >> with #ifdefs, or gratuitously rename controller driver file names or >> "config names" just so you can build a kernel both ways. > >IMHO, with that attitude you can take the CAM stuff and go play >somewhere else. 8-) I have been playing somewhere else for 8+ months. I'm more than content to continue to do that as my primary goal is to complete a robust and clean I/O subsystem. I'm not in any hurry to get the code integrated which means that I'm not going to spend a single moment dirtying up the code so that it can be integrated in advance of when it is 100% ready. As I told Mike Smith shortly after reading his message about a flag day, integrating this code into current now is contradictory to my goal of having the system 100% functional when the "CAM flag day" occurs. >Part of being a 'team effort' means making compromises >so that everyone can work together. The people who wish to contribute toward the goal of CAM integration into current (i.e. hitting that 100% ready mark) are more than welcome to complete access to the Perforce repository where the code is developed. Several developers already have this access and aren't pleading for the ability to build the old SCSI layer from the same code base. >Alienating the entire -current code-base with no backwards path to do >upgrade of local changes might be easier for you, but it's a nightmare >for anyone that isn't intimately familiar with how the CAM stuff is >written, which affects everyone but you. Who am I alienating and how? Am I alienating people because I insist that the CAM code be completely and fully implemented before being integrated? I won't push code into the tree that is incomplete or doesn't function for some people. I think that examples like DEVFS, devconfig, etc. make my case for not doing so better than I could ever with words. If CAM offers the same support (plus more) as the current SCSI code when it is integrated, then most users won't even notice a difference. Those that do will see increased performance and/or reliability. Why would I want to put #ifdef crap in the code if my 8 month long goal has been to integrate CAM into current only when it is ready? >> If you want the code to go on a branch first, fine by me, but it is my >> intention to only put the code into CVS at all once the minimum amount >> of device support acceptable to users of current has been developed >> and tested. > >Minimum acceptable w/out giving people who don't fit into the group is >unacceptable. I can't parse this. >Nate -- 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?199804232045.OAA11155>