Date: Tue, 3 Mar 1998 23:50:07 -0700 (MST) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: Tom <tom@sdf.com> Cc: hackers@FreeBSD.ORG Subject: Re: do you support Message-ID: <199803040650.XAA14156@narnia.plutotech.com> In-Reply-To: <Pine.BSF.3.95q.980226230152.19894F-100000@misery.sdf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <Pine.BSF.3.95q.980226230152.19894F-100000@misery.sdf.com> you wrote: > > On Thu, 26 Feb 1998, Mike Smith wrote: > >> > Then I'll consider you surprised then, because it is running CAM. >> >> I am surprised. 8) I wonder if the demon that did the backport would >> consider bundling it such that we could ship it as an optional extra? > > Well, this was discussed on freebsd-scsi I believe... > > Justin and/or Dave G are working on making a patchkit for 2.2-stable I > believe. I did the port of CAM back to 2.2 in December of last year after David called me up to complain, yet again, of instability in our current SCSI code. The patches have "rotted" and won't work with the most recent snapshot, but I plan to release patches for 2.2 in the next CAM snapshot (real soon now... I promise! 8-). > There is is even talking including CAM in the 2.2 branch after > 2.2.6. I suspect that would be done as a kernel option, because some > drivers are not CAMified yet. Not exactly. I talked about bringing into stable a few of the changes from current upon which CAM relies, to make it almost trivial to drop CAM into either current or stable. CAM may wind up on a branch in the near future, but it will not be "standard" in either current or stable until all current devices are supported. To respond to a few other comments in this thread: There are problems in the ahc driver in current that I've known about for some time. I'm sorry that certain users are plagued by these bugs, but I can't do anything more about them than I am already. Several of these bugs are simply unfixable in the SCSI framework in current. Instead of attempting patch after patch to attempt to hack around these issues, I decided to write the CAM code instead. I know it doesn't help that the last snapshot we released doesn't apply cleanly to a current, current, but I am working hard on rectifying this. So why is it that the NCR driver works so well? I think this is more a matter of perspective than fact. There are users of both the Adaptec and NCR cards that will say they work flawlessly and users who say they break in configuration X. It's my hope that as CAM is a much cleaner framework, we will be able to resolve these issues swiftly as CAM receives more testing. As for CAM being for the "true hacker" only, I don't think this needs to be the case. I'm focusing now on getting the next snapshot out so that proper installation media can be generated and once this is done, I don't anticipate users that can live with the limited device support in CAM having any reliability issues. The feature set of CAM grows daily and I hope that more and more people try using it. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803040650.XAA14156>