From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: Error reporting in Netlink (Re: Xtables2 Netlink spec) Date: Fri, 17 Dec 2010 00:31:15 +0100 Message-ID: <4D0AA143.3090608@trash.net> References: <1292507013.3395.19.camel@lsx> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Jan Engelhardt , Jesper Dangaard Brouer , Jozsef Kadlecsik , Netfilter Developer Mailing List , netfilter@vger.kernel.org, Pablo Neira Ayuso To: tgraf@redhat.com Return-path: In-Reply-To: <1292507013.3395.19.camel@lsx> Sender: netfilter-owner@vger.kernel.org List-Id: netfilter-devel.vger.kernel.org Am 16.12.2010 14:43, schrieb Thomas Graf: > Thinking of netlink protocols in general and netfilter in specific, > maintaining a list of reserved error codes for each subsystem/target/ > module will result in an unbearable pain if the error codes are not > separated into individual namespaces for each module. > > That would in turn require each module to define a unique number or > some form of namespace resolution mechanism which does not help to keep > things simple. > > This is the main reason why I advocate the use of error strings. 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.