On Thursday 2010-12-16 15:47, Jozsef Kadlecsik wrote: >> >> 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. >> >> That would in turn require each module to define a unique number or >> some form of namespace resolution mechanism which does not help to keep >> things simple. >> >> This is the main reason why I advocate the use of error strings. > >But why error codes looks complicated? Netlink already supports it and >it's simple to separate them: > errcode < 256 generic errors >256 <= errcode < 512 generic netfilter specific errors >512 <= errcode table/match/module specific errors Actually, <4096 is reserved for the generic system errors (Exxx). The specific issue here however is that you cannot easily delegate the space >=512 to modules, so it's probably best if we don't try. >>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. Error messages produced by the kernel >>should be the exception and not a substitute for proper userspace error >>handling. > >Netlink based protocol is the path to internationalization. Netlink based >protol leads to usable library. Library leads to gui. Gui leads to >internationalization. ;-) On the contrary: "Users leads to guis, guis lead to requests, requests lead to libraries, libraries lead to netlink. Doesn't make sense? Ask SUN!" -- 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
