From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Jan Engelhardt <jengelh@medozas.de>,
Thomas Graf <tgraf@redhat.com>,
Jesper Dangaard Brouer <hawk@diku.dk>,
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>,
Netfilter
Subject: Re: Error reporting in Netlink (Re: Xtables2 Netlink spec)
Date: Fri, 17 Dec 2010 11:00:52 +0100 [thread overview]
Message-ID: <4D0B34D4.9020208@netfilter.org> (raw)
In-Reply-To: <20101216141923.GB23297@canuck.infradead.org>
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.
next prev parent reply other threads:[~2010-12-17 10:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-24 22:29 Xtables2 Netlink spec Jan Engelhardt
2010-11-26 19:01 ` Jozsef Kadlecsik
2010-12-09 12:08 ` Pablo Neira Ayuso
2010-12-14 2:01 ` Jan Engelhardt
2010-12-14 2:16 ` James Nurmi
2010-12-14 3:46 ` Jan Engelhardt
2010-12-15 13:54 ` Pablo Neira Ayuso
2010-12-16 14:05 ` Thomas Graf
2010-12-16 14:22 ` Jan Engelhardt
2010-12-17 7:25 ` Thomas Graf
2010-12-17 9:35 ` Jan Engelhardt
2010-12-17 9:50 ` Pablo Neira Ayuso
2010-12-17 9:55 ` Pablo Neira Ayuso
2010-12-17 14:56 ` Jan Engelhardt
2010-12-15 4:55 ` Jan Engelhardt
2010-12-15 8:51 ` Jozsef Kadlecsik
2010-12-16 9:57 ` Jesper Dangaard Brouer
2010-12-16 12:51 ` Error reporting in Netlink (Re: Xtables2 Netlink spec) Jan Engelhardt
2010-12-16 13:43 ` Thomas Graf
2010-12-16 13:51 ` Jan Engelhardt
2010-12-16 14:19 ` Thomas Graf
2010-12-17 10:00 ` Pablo Neira Ayuso [this message]
2010-12-16 14:47 ` Jozsef Kadlecsik
2010-12-16 15:09 ` Jan Engelhardt
2010-12-16 23:31 ` Patrick McHardy
2010-12-17 6:58 ` Thomas Graf
2010-12-16 23:23 ` Patrick McHardy
2010-12-17 10:02 ` Pablo Neira Ayuso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D0B34D4.9020208@netfilter.org \
--to=pablo@netfilter.org \
--cc=hawk@diku.dk \
--cc=jengelh@medozas.de \
--cc=kadlec@blackhole.kfki.hu \
--cc=tgraf@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox