On Thursday 2010-12-16 14:43, Thomas Graf wrote: > >>It also does not look very netlinky to not use nlattrs > >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? >>>>But I do realize that it's much easier (and therefore quite >>>>tempting) to construct the full error message in kernel space and >>>>just send it back. However, that'd make quite hard to support >>>>internationalization. > >Thinking of netlink protocols in general and netfilter in specific, >maintaining a list of reserved error codes for each >subsystem/target/ module will result in an unbearable pain if the >error codes are not separated into individual namespaces for each >module. I did not plan on giving extensions a numeric namespace; here it's largely strings only. >> It's not like those strings change all that much. >> >> >To support internationalization, we could just add an error-number-code >> >in front of the constructed error message? >> >> Buying us what? If you change the string, but the gettext lookup is >> based upon a number, you will get an outdated translation, which is not >> nice either. IMHO: Better an English message than an inaccurate message. > >Do we *really* need internationalization for error messages on this >level? Primarily userspace should be in charge of checking for all kinds >of erroneous user input and produce meaningful context based, >translatable error messages. 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. -- 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
