Date: Sat, 15 Dec 2007 16:11:01 -0800 From: "Kip Macy" <kip.macy@gmail.com> To: "Robert Watson" <rwatson@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support Message-ID: <b1fa29170712151611x59117495le072020cb2819069@mail.gmail.com> In-Reply-To: <20071215214253.N85668@fledge.watson.org> References: <b1fa29170712121303x537fd11fj4b8827bb353ad8e4@mail.gmail.com> <b1fa29170712150057m690bd36bm7a1910969e92293b@mail.gmail.com> <20071215100351.Q70617@fledge.watson.org> <b1fa29170712151040icb371efseaf61d9b79907b24@mail.gmail.com> <20071215190252.I85668@fledge.watson.org> <b1fa29170712151144y2677aebftc1ed83011a3d32fe@mail.gmail.com> <20071215214253.N85668@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Actually, what I was asking for in the omitted context above was something > along the lines of the following, adapted for whatever the reality may be: > > Returning a non-zero value will lead to the software stack beginning a > disconnect. > > Or, say, > > Non-zero return values will be ignored. (*) > > This is not intended as a contrarian point. I'm not looking for a complete > exposition of the behavior of the stack -- rather, basic information that we > should be documenting about a KPI, such as what an error being returned will > do. I believe that my latest patch makes at least a perfunctory effort to address all of the points you've raised with the notable exception of widening the ops vector. Please take a quick look at the same URL as before. -Kip
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1fa29170712151611x59117495le072020cb2819069>