On Sun, 15 Oct 2006 17:16:35 -0700 David Brownell <[EMAIL PROTECTED]> wrote:
> > > You, the driver author _do not know_ what pci_set_mwi() does at present, on > > all platforms, nor do you know what it does in the future. > > I know that it enables MWI accesses ... or fails. Beyond that, there > should be no reason to care. If the hardware can use a lower-overhead > type of PCI bus cycle, I want it to do so. If not, no sweat. > There are two reasons why it can fail: 1: The bus doesn't support MWI. Here, the caller doesn't care. 2: The bus _does_ support MWI, but the attempt to enable it failed. Here we very much do care, because we're losing performance. > > > This is not a terribly important issue, and it is far from the worst case > > of missed error-checking which we have in there. > > The reason I think it's important enough to continue this discussion is > that as it currently stands, it's a good example of a **BAD** interface > design ... since it's pointlessly marked as must_check. (See appended > patch to fix that issue.) It's important to continue this discussion so that certain principles can be set and agreed to. Because we have a *lot* of unchecked errors in there. We would benefit from setting guidelines establishing - Which sorts of errors should be handled in callers - Which sorts of errors should be handled (ie: just reported) in callees - Which sorts of errors should be handled in neither callers nor callees (are there any of these?) - Whether is it ever legitimate for a caller to not check the return code from a callee which can return -EFOO. (I suspect not - it probably indicates a misdesign in the callee, as in this case). - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
