Date: Mon, 22 Sep 1997 13:07:22 -0600 (MDT) From: Nate Williams <nate@mt.sri.com> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: Bruce Evans <bde@zeta.org.au>, current@freebsd.org, nate@mt.sri.com 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: <199709221907.NAA02110@rocky.mt.sri.com> In-Reply-To: <199709221501.JAA16510@pluto.plutotech.com> References: <199709221440.AAA18001@godzilla.zeta.org.au> <199709221501.JAA16510@pluto.plutotech.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. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709221907.NAA02110>