Date: Mon, 22 Sep 1997 14:40:03 -0600 (MDT) From: Nate Williams <nate@mt.sri.com> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: Nate Williams <nate@mt.sri.com>, Bruce Evans <bde@zeta.org.au>, current@freebsd.org Subject: callouts in CAM (was Re: cvs commit:) Message-ID: <199709222040.OAA02694@rocky.mt.sri.com> In-Reply-To: <199709222037.OAA01057@pluto.plutotech.com> References: <199709221907.NAA02110@rocky.mt.sri.com> <199709222037.OAA01057@pluto.plutotech.com>
index | next in thread | previous in thread | raw e-mail
Justin T. Gibbs writes: > >> The current implementation only needs to allocate a callout at a time if > >> it wants to grow the number of callouts. It may, in fact be nice to add > >> an interface for clients to add additional callouts if they are heavy > >> users of them. For instance, the CAM system grows it's number of > >> transactions dynamically and will simply stop growing if it can't malloc > >> more. In your scenario, if you can't allocate space for a drive and it's > >> transactions, you can't talk to the drive. > > > >Umm, how does the CAM system still talk to a drive if it can't establish > >a callout for it? If it can do that now, then it can certainly do it > >with the old solution. > > I assume that I can allocate a single CCB/callout at boot time. If this > is the case, I can talk to any number of devices by serializing the > transactions. It won't be fast, but it won't fail either. > > CCB = CAM Control Block - a structure used to encapsulate a CAM > transaction. Couldn't you do this with the old setup as well, since you have access to the callouts at boot time in both schemes? Natehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709222040.OAA02694>