On 17/12/10 00:23, Patrick McHardy wrote: > Am 16.12.2010 13:51, schrieb Jan Engelhardt: >> On Thursday 2010-12-16 10:57, Jesper Dangaard Brouer wrote: >> >>> Cc.ed Thomas Graf (tgraf@xxxxxxxxxx), Thomas presented some interesting >>> ideas on netlink error-codes and strings during NetConf 2010, see: >>> >>> http://vger.kernel.org/netconf2010.html >>> http://vger.kernel.org/netconf2010_slides/tgraf_netconf10.odp >> >> The idea is appending an error string is ok for Netlink as a protocol >> (specification-wise), but the size constraints of the skbuffs in the >> Linux may make its practical implementation a little harder. "Half of >> the packet" is already used for the original request message, and >> cramming an extra error string may bust the space. >> It also does not look very netlinky to not use nlattrs ;-) > > I agree, error strings don't look like a viable solution to me, > they are basically impossible to interpret by an application, > you run into localization issues and so on. > > I'd suggest to return an errno value and the attribute causing > the error, possibly also the value (we append the original message > anyways, but in case of lists it might be hard to locate the specific > attribute). The harder cases are when a combination of multiple > attributes are responsible for the error, but still, the application > has to understand the kernel interpretation anyways, so I'd simply > return the errno and all attributes responsible. Leave interpretation > up to userspace. I'd also prefer an int. We can define the meaning of the error numbers in the protocol header file. -- 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