[Top] [All Lists]

Re: [RFC] Extend netlink error codes

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: [RFC] Extend netlink error codes
From: Thomas Graf <tgraf@xxxxxxx>
Date: Mon, 13 Sep 2004 22:36:57 +0200
Cc: Sam Leffler <sam@xxxxxxxxx>, Andi Kleen <ak@xxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <1094937035.2344.189.camel@xxxxxxxxxxxxxxxx>
References: <20040910225158.GO20088@xxxxxxxxxxxxxx> <20040911155839.GN4431@xxxxxxxxxxxxx> <20040911162433.GC21181@xxxxxxxxxxxxxx> <3A0D075D-0423-11D9-BBE1-000A95AD0668@xxxxxxxxx> <1094937035.2344.189.camel@xxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
* jamal <1094937035.2344.189.camel@xxxxxxxxxxxxxxxx> 2004-09-11 17:10
> On Sat, 2004-09-11 at 14:48, Sam Leffler wrote:
> just reuse skb->cb[] and intepret it in rtnetlink in the case of
> failures.

Good idea, however it means to change a lot of APIs used by modules
to provide the skb or a pointer to the error string buffer.

I still think it would be best to transport the error code via
the return value in order to not change any static APIs, but
I guess that 32bit is not enough to store errno and the id
your propose below.

> I think we need to identify errors by IDs - dont think we can avoid
> that. The IDs could be the T in TLV; their scope is per socket level (eg
> at rtnetlink); This means there are 16 bits space per socket type.
> The next level to addressing is at each submodule level eg qdisc,
> ipv4route, etc. Assuming we have 8 bits there that leaves upto 8 bits
> per submodule for different error types. 256 error codes per submodule
> liek a qdisc sounds very reasonable to me. We could reserve the last
> entry for future extensions. Example:
> socket: rtnetlink
> submodule: qdisc (module 1)
> error id: Q_NASTYTHING which is 0x10
> qdisc_errors[Q_NASTYTHING] is "something really nasty just happened"

Sounds reasonable to me.

> BTW, there was someone from IBM a while back who was talking about
> having drivers send error messages via netlink; someone needs to look at
> the ideas they have maybe we can borrow something.

I read trough the patch and what they basically provide is a way to send
data to a netlink socket. The data can be collected via an own netlink
socket by subscribing to it or use the user space daemon.

They provide stuff like:

evl_printf(const char *facility, int event_type, int severity,
        const char *fmt, ...)

usage could be something like:

evl_printf("qdisc", Q_NASTYTHING, ...

We could use it this way:
- Leave the existing error system as it is
- Make the netlink users send out error messages on their own.
  pid and sequence number of the original netlink message could be
- User space applications could fetch error messages from that socket
  and assign them to their own actions by sequence number and pid.

 - Almost no changes to the APIs
 - Easy to implement
 - No problem with distribution of error codes
 - Very easy to implement formatted error strings.

 - More work for user space
 - How does user space know if there will be an extended error?
   If unknown, how long to wait?
 - Should we allow sending of errors to this socket while no
   netlink message is being processed?

Idea: Make user space applications poll on the socket and
just print the errors async. This would allow netlink users to
use it for more than just error handling.

<Prev in Thread] Current Thread [Next in Thread>