* Andi Kleen <20040911165056.GQ4431@xxxxxxxxxxxxx> 2004-09-11 18:50
> I was thinking about a variable length netlink packet
> that contains it and that is sent back to the application.
All solutions discussed so far are based on sending a netlink
message back to the application. Changing the existing
nlmsgerr.error or adding a TLV with an error message doesn't
make much difference from an implementors view.
> No need to store it anywhere else.
Not storing it would mean to call netlink_ack from everywhere
which requires knowledge of the original netlink skb and the
original netlink message in order to get the pid and sequence
number right. (We can't use the pid assigned to the peer's
sock.) It would also mean to set a bit to avoid sending out
the ack again. Wrong?
> On the other hand there are not
> that many sched/cls modules and some minor changes to them
> are probably ok.
True, but also think of xfrm, tcp_diag, netfilter, dnrmg. I haven't
checked how much work it would actually be to improve better
error messages for them but I plan to at least extend all
error codes related to the data passed via a netlink socket.
Will wait for some comments. I guess I would be swamped with
something like discussed above.
|