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

[Thomas Graf <tgraf@redhat.com>]

On Fri, 2010-12-17 at 00:31 +0100, Patrick McHardy wrote: 
> I completely disagree. As I said previously, userspace has to have
> knowledge of the kernel interpretation anyways.
> 
> We already have libc calls which define complex errors like:
> 
> stdtod(): if val == HUGE_VAL && errno == ERANGE: positive overflow
> 
> I see no reason why we can't define combination of attributes
> and errno values for netlink messages.
> 
> Something like:
> 
> [IFLA_VLAN_ID] == NULL && errno == EINVAL: missing attribute
> [IFLA_VLAN_LINK] && errno == ENODEV: lower link does not exist
> 
> and so on.

Using strings would still involve including an errno as we currently
do and as I pointed out in my other mail I am also very positive
about including an offset pointer or a attribute type to specify the
attribute that caused the failure.

Maybe I am thinking too much about other netlink protocols where
errors often occur due to complicated combinations of missing attributes
and specific attribute values having special meanings. Those cases
would benefit a lot from error strings.

I really don't want to see:

return nl_errstring(ENOMEM, "Out of memory");

I am aiming at a verbose error or status string which acts as an
additional helping point in case of complicated errors. I really
don't want to replace the method of using errno to report errors
in general.

I thought about using attrs to specify the error and the reason I
did choose strings was that when we introduce new errors in the
kernel we have to update all applications. Which is no problem if
everyone uses libraries, so it is probably trivial for netfilter but
will be less trivial for netlink users as a group.

That said, I completely understand your point of view a well.