Date: Sun, 26 Apr 1998 09:46:09 -0700 (PDT) From: Simon Shapiro <shimon@simon-shapiro.org> To: "Justin T. Gibbs" <gibbs@narnia.plutotech.com>, scsi@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: A CAM of worms Message-ID: <XFMail.980426094351.shimon@simon-shapiro.org> In-Reply-To: <199804231753.LAA26658@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980426094351.shimon>