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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709222040.OAA02694>