On 02.02.2011 07:40, Patrick McHardy wrote: > On 01.02.2011 20:43, Jozsef Kadlecsik wrote: >> On Tue, 1 Feb 2011, Patrick McHardy wrote: >> >>> I guess you're relying on that the original message is appended to a >>> nlmsgerr message. That doesn't seem right though, if you want to return >>> something to userspace, you should construct a new message. >> >> The message we are processing here carried multiple commands (each having >> an attribute with the line number of the given command) and one failed >> from some reason. We have to notify the userspace which command, at what >> line failed. For this reason the multi-command messages have got an >> attribute, which can be filled out with the line number - that happens >> here. The attribute is already there, the message is not enlarged, just >> the empty value is overwritten with the proper value. >> >> The line number reporting works this way, tested in the testsuite too. > > I'm still not really clear how this works since the message contents > have been copied from userspace, so modifying the contents seems > useless. I'll have a closer look at userspace to understand how this > works. > >> If I had to construct a completely new message and sent it, that'd be more >> or less the duplication of netlink_ack. Additionally I had to suppress >> netlink from sending an errmsg/ack too. >> >> If one can't rely on the modifiable message and nlmsgerr, then the error >> reporting in netlink is, hm, not really useful :-( > > I'm mainly not clear about how this works at all, will have a closer > look at userspace :) OK, it does what I expected initially, rely on the contents to be appended to the nlmsgerr and decode that message in userspace. It's somewhat creative use, but I guess there's nothing fundamentally wrong doing this. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
