Date: Mon, 22 Sep 1997 14:37:10 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Nate Williams <nate@mt.sri.com> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, Bruce Evans <bde@zeta.org.au>, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... Message-ID: <199709222037.OAA01057@pluto.plutotech.com> In-Reply-To: Your message of "Mon, 22 Sep 1997 13:07:22 MDT." <199709221907.NAA02110@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709222037.OAA01057>