From owner-freebsd-current Thu Apr 23 10:58:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA20741 for freebsd-current-outgoing; Thu, 23 Apr 1998 10:58:47 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA20731 for ; Thu, 23 Apr 1998 10:58:45 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id LAA26658; Thu, 23 Apr 1998 11:53:32 -0600 (MDT) Date: Thu, 23 Apr 1998 11:53:32 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199804231753.LAA26658@narnia.plutotech.com> To: shimon@simon-shapiro.org cc: current@FreeBSD.ORG Subject: Re: A CAM of worms Newsgroups: pluto.freebsd.current In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I am sorry to have joined this discussion so late. I was on the road and > no access to the net for all this time. I hope you have read the full thread and know that this announcement (which has hence been called off) was as much a surprise for me as it was for anyone else. > 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. 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. > * 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. > * 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. > Simon -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message