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. 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. > Let's see, why does iproute2 not just do that, then? Because some > things only the kernel knows about, so even if the parameters are > correct from the userspace side of view, the kernel may reject the > request nevertheless. You are not the first to come up with this but it is still a pretty lazy excuse. iproute2 could do a lot better than it does today and it has been improved a lot over time. The main reason for the current situation is the atomic nature of routing netlink requests handlers. Checking for errors in an atomic context where no interface disappears and no route can be removed while the request is being processed simply makes checking for errors a lot easier. This does not mean that userspace should have a card blanche for sending bogus combinations of netlink attributes and expect the kernel to always come up with a perfect verbose error message. The kernel can still send ENODEV to indicate the specified network device does not exist but it should only cover the case where the interface disappeared between the userspace checking for its existance and the request being processed. -- 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
