RFR 8046588: test for SO_FLOW_SLA availability does not check for EACCESS

[Chris Hegarty]

On 12/06/14 21:04, Michael McMahon wrote:
> On 12/06/14 20:35, Alan Bateman wrote:
>> On 12/06/2014 20:15, Michael McMahon wrote:
>>>
>>> It would be possible to change the error back, but what about
>>> supportedOptions() - what should
>>> that return? It doesn't seem right that it would include an option
>>> that cannot be used and how do
>>> we test it, if we can't tell whether the option is usable or not?
>>>
>>> Maybe it depends on how these privileges get configured, which is
>>> something I'm looking into,
>>> but if it's a case that specific user attributes need to be
>>> configured on a system, then I'm not sure
>>> we can count on that for our test systems.
>> On platforms where the support option is supported then I would think
>> that supportedOptions should include it, otherwise I could imagine
>> users getting confused by the UOE.

I think I agree with Alan here. If the platforms support the option, 
then supportedOptions() should include it.

 >> For the tests then having them pass
>> then the option is supported but can't be set due to lack of
>> privileges seems reasonable to me. I guess it's a subjective and maybe
>> others might have opinions on this.
>>
>> -Alan.
>
> But we don't have a distinction between the exception thrown from EACCES
> and E not supported (or whatever it is).

This is tricky, and adds a new dimension to socket option access, that I 
didn't realize when this was added.

> I don't think we want to start parsing error strings ....?

Short of a new unchecked Exception type, then I think we can only depend 
on the exception message ( not pretty! ).

-Chris.

> Michael