> > These return values seem mutually exclusive. Surely we're not going to see > > a > MAD with status 'busy - redirection required - bad version - success'? > > They are mutually exclusive now but because the spec defines separate fields > it > might not always be that way. That is what I meant when I said "status is not > defined to be a strict enum".
Is there some other option here? The user doesn't know how large this buffer needs to be. - Per thread internal static variable, so the user doesn't need to allocate the buffer? - Since status is defined as multiple fields, have calls for each field? - Two status string calls, one to return enum type values, and the other to deal with fields? This basically tries to output a single string from multiple fields, which seems confusing. But I dislike saying "not busy, no redirection required, and no invalid fields" rather than "success", even if it is technically more correct. Is it acceptable to treat status as an enum, and switch to per thread static variables or multiple calls later if the need ever arises? - Sean -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
