From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pablo Neira Ayuso Subject: Re: Error reporting in Netlink (Re: Xtables2 Netlink spec) Date: Fri, 17 Dec 2010 11:00:52 +0100 Message-ID: <4D0B34D4.9020208@netfilter.org> References: <1292507013.3395.19.camel@lsx> <20101216141923.GB23297@canuck.infradead.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20101216141923.GB23297@canuck.infradead.org> Sender: netfilter-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Jan Engelhardt , Thomas Graf , Jesper Dangaard Brouer , Jozsef Kadlecsik , Netfilter On 16/12/10 15:19, Thomas Graf wrote: > On Thu, Dec 16, 2010 at 02:51:07PM +0100, Jan Engelhardt wrote: >>> Why not use nlattr to encode the error string? It would make error >>> messages easier to extend in the future. At some point we might want >>> to add an offset field which points into the original netlink >>> message describing the attribute which caused the failure. >> >> Is that a yes or a no? > > The proposed solution at netconf involved appending the error string > directly. Inspired by your comment I realizezd that encoding the > error string as nlattr allow for additional attributes would be a > better implementation. Indeed, I'd prefer adding an extra netlink header with a new type like NLM_ERROR2 followed by attributes like the string (or an int) that contain the error. This also can be added with breaking existing apps and libraries IIRC. > As for size limitations, even though most netlink protocols do it, I > don't see the point in appending the whole request message in a error > message. The header would be completely sufficient for all request/reply > based protocols. It is no problem for userspace to keep a copy of the > last request sent. At least, we require the netlink header of the request message in error messages. This is useful for message batches that are sent to kernel-space, to know which one triggered the error.