On Tue, Dec 29, 2009 at 9:54 AM, Sasha Khapyorsky <sas...@voltaire.com> wrote:
> On 11:08 Mon 28 Dec , Hal Rosenstock wrote:
>> >>
>> >> A subsequent patch will reintroduce this checking based on an additional
>> >> option which will default to not do this.
>> >
>> > I think that addition of such sort of options (eg "--workaround-bugX")
>> > should be avoided unless it is absolutely necessary.
>>
>> I was thinking something like --qos-init-error with a description.
>>
>> > And even then more generic stuff would be better.
>> >
>> > In this specific case more generic option like:
>> > '--resweep-on-failed-attr=11,15' (with reasonable default) will be more
>> > useful for dealing with this and maybe another potential issues.
>>
>> Where else do you see this as being useful ?
>
> In this case at least. I had some questions in the past about how
> to ignore some sort of initialization errors.
What (other) initialization errors should be ignored ? Isn't this
dangerous and slippery slope ?
> Another potential use is
> to extended this to SubnGet() responses errors handling too when
> requested.
That would require additional changes beyond what is being discussed
here and might not come from the same attribute list so it's unclear
to me whether or not this is related (in terms of configuration).
>> Is such flexibility really needed or is this more "just in case" ?
>
> See above.
> Anyway it is better than introducing '--qos-init-error',
> ('--pkey-init-error', etc.) and not much harder to implement.
Sure; the question was it's necessity and not it's implementation "difficulty.
-- Hal
> Sasha
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
