From owner-freebsd-current Thu Apr 23 13:22:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA19285 for freebsd-current-outgoing; Thu, 23 Apr 1998 13:22:49 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA19249 for ; Thu, 23 Apr 1998 13:22:41 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA27379; Thu, 23 Apr 1998 14:21:24 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA11026; Thu, 23 Apr 1998 14:18:51 -0600 Date: Thu, 23 Apr 1998 14:18:51 -0600 Message-Id: <199804232018.OAA11026@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: shimon@simon-shapiro.org, current@FreeBSD.ORG Subject: Re: A CAM of worms Newsgroups: pluto.freebsd.current In-Reply-To: <199804231753.LAA26658@narnia.plutotech.com> References: <199804231753.LAA26658@narnia.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > My exceptions to the proposed plan: > > > > * No migration path; The is no mechanism to migrate at all. We need a > > way to have the same system boot either way. We need a mechanism to > > maintain source for the old systems and switch back. > > 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. Part of being a 'team effort' means making compromises so that everyone can work together. 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. > 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. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message