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. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
