Re: Error reporting in Netlink (Re: Xtables2 Netlink spec)

[Pablo Neira Ayuso <pablo@netfilter.org>]

On 17/12/10 00:23, Patrick McHardy wrote:
> Am 16.12.2010 13:51, schrieb Jan Engelhardt:
>> On Thursday 2010-12-16 10:57, Jesper Dangaard Brouer wrote:
>>
>>> Cc.ed Thomas Graf (tgraf@redhat.com), Thomas presented some interesting 
>>> ideas on netlink error-codes and strings during NetConf 2010, see:
>>>
>>> http://vger.kernel.org/netconf2010.html 
>>> http://vger.kernel.org/netconf2010_slides/tgraf_netconf10.odp
>>
>> The idea is appending an error string is ok for Netlink as a protocol
>> (specification-wise), but the size constraints of the skbuffs in the
>> Linux may make its practical implementation a little harder. "Half of
>> the packet" is already used for the original request message, and
>> cramming an extra error string may bust the space.
>> It also does not look very netlinky to not use nlattrs ;-)
> 
> I agree, error strings don't look like a viable solution to me,
> they are basically impossible to interpret by an application,
> you run into localization issues and so on.
> 
> I'd suggest to return an errno value and the attribute causing
> the error, possibly also the value (we append the original message
> anyways, but in case of lists it might be hard to locate the specific
> attribute). The harder cases are when a combination of multiple
> attributes are responsible for the error, but still, the application
> has to understand the kernel interpretation anyways, so I'd simply
> return the errno and all attributes responsible. Leave interpretation
> up to userspace.

I'd also prefer an int. We can define the meaning of the error numbers
in the protocol header file.