From owner-freebsd-current Sun Apr 26 08:48:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA12239 for freebsd-current-outgoing; Sun, 26 Apr 1998 08:46:29 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero-fddi.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA12070 for ; Sun, 26 Apr 1998 08:45:16 -0700 (PDT) (envelope-from shimon@sendero-fddi.simon-shapiro.org) Received: (qmail 9946 invoked by uid 1000); 26 Apr 1998 16:46:10 -0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Message-ID: X-Mailer: XFMail 1.3-alpha-040798 [p0] on FreeBSD X-Priority: 3 (Normal) In-Reply-To: <199804231753.LAA26658@narnia.plutotech.com> Date: Sun, 26 Apr 1998 09:46:09 -0700 (PDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: "Justin T. Gibbs" , scsi@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: A CAM of worms Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Apr-98 Justin T. Gibbs wrote: ... >> * 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. 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. I have no argument here... >> * No migration guide; The is no documentation on the new mechanism, its >> interfeaces, requirements, etc. I asked, several times, politely, >> and >> privately, for at least a list of functions, their intended purpose >> and >> the entry points into both HBA drivers and personality drivers. The >> ``I >> do not have time'' answer is simply not enough. If there is no time >> to >> list the API's maybe the code change should be held until there is >> time. > > This is in the works and will be available long before any potential flag > day. Great! I really want to move the DPT driver to CAM, but with a new job and all I want to make sure I do it as intended (by you, in designing CAM) and not as guessed (by me, reading the driver to one particular HBA or another). >> * The idea of overnight obsolesence of all the existing SCSI code is a >> bit, shall we say, aggressive. Although I have all the confidence in >> the >> world that the CAM code is wonderfully reliable, efficient and great, >> sone of us earthly mortals would like to have a chance to compile and >> run >> the two systems side by side, at least until the porting is done. > > Overnight? This project has been in the works for several months. If > you have concerns about the CAM architecture the code has been available > for you to run and review for some time. This is not my issue at all. I stated before that I trust it is good and correct. But my (aparently wrong) impression that the 28th of April signifis a drop in the support for the (still) current architecture led me to think that in two days from now All the kernel will support is CAM, and non-CAM systems are out in the cold. I am glad to see that I was wrong. Simon BTW, Your mail still arrives here with: Nn:Pluto.freebsd.current, and I still am not allowed to post to that newsgroup :-) Simon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message