From owner-freebsd-current Thu Apr 23 13:40:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA21592 for freebsd-current-outgoing; Thu, 23 Apr 1998 13:40:23 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pop.uniserve.com (pop.uniserve.com [204.244.156.3]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA21536 for ; Thu, 23 Apr 1998 13:40:12 -0700 (PDT) (envelope-from tom@uniserve.com) Received: from shell.uniserve.ca [204.244.186.218] by pop.uniserve.com with smtp (Exim 1.82 #4) id 0ySSlB-0003Q0-00; Thu, 23 Apr 1998 13:38:21 -0700 Date: Thu, 23 Apr 1998 13:38:19 -0700 (PDT) From: Tom X-Sender: tom@shell.uniserve.ca To: Nate Williams cc: "Justin T. Gibbs" , shimon@simon-shapiro.org, current@FreeBSD.ORG Subject: Re: A CAM of worms In-Reply-To: <199804232018.OAA11026@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 23 Apr 1998, Nate Williams wrote: > > There is certainly a migration path. Run a CAM kernel or don't. Most > > 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. I don't understand what in Justin's "attitude" you've found offensive. The current SCSI layer has bugs. CAM fixes most of those and adds new drviers. CAM is the future. It is time that we got past this. Hell, even wcarchive uses CAM now (back-ported to 2.2) as it is just more stable code. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message