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. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
