Re: [PATCH 2/9] netfilter: xtables: slightly more detailed checkentry return values

[Patrick McHardy <kaber@trash.net>]

Patrick McHardy wrote:
> Jan Engelhardt wrote:
>> On Wednesday 2010-03-17 15:16, Patrick McHardy wrote:
>>>>> I guess this makes sense, however iptables has special interpretations
>>>>> of errno values. How will this interact?
>>>> Since we are "just going back", the effect should be none - dig out
>>>> an old iptables and kernel and you get the same environment.
>>> No, we're now returning additional errno values from modules.
>>>
>>>> Well, libiptc prints a few specialized error messages for certain
>>>> codes (cf libiptc.c, TC_STRERROR), else uses plain libc strerror.
>>> That's what I was talking about. Unfortunately quite a few
>>> of the reasonable combinations have special meaning, f.i.
>>> TC_INIT/ENOENT, TC_INIT/EINVAL, ...
>> We need only be concerned about TC_COMMIT (which calls setsockopt
>> with SO_SET_REPLACE, which leads to checkentry).
>>
>> TC_COMMIT returns 0 or 1, with errno set from what setsockopt
>> left - this will be the error code, as it is also just propagated
>> inside the kernel, if I read it right.
>>
>> So flow control ends up at iptables-standalone.c at the end
>> and the errno code is just used for printing/choosing an error code.
>>
>> If I missed something, please enlighten me.
> 
> OK that seems mostly fine. Basically its just the NULL/ENOENT
> interpretation that might be confusing.

One more thing though - I really don't like the strange mix of booleans
and errno codes. If you want to change this, please switch to the
standard convention of 0 == no error, < 0 == errno code. For unspecific
errors you can simply return EINVAL as the xt_check_*() functions
currently do.