On Tuesday 2012-02-14 01:24, Pablo Neira Ayuso wrote:
>On Mon, Feb 13, 2012 at 10:38:53AM +0100, Jan Engelhardt wrote:
>> On Monday 2012-02-13 10:06, Pablo Neira Ayuso wrote:
>>
>> >On Wed, Feb 08, 2012 at 04:49:07PM +0100, Jan Engelhardt wrote:
>> >> On Wednesday 2012-02-08 16:16, Mr Dash Four wrote:
>> >>
>> >> >
>> >> >> "ENOENT has many meanings, and iptables prints just one of them,
>> >> >> which is potentially misleading."
>> >> >>
>> >> > Thanks, this will be corrected I take it?
>> >>
>> >> Is this wording compatible enough with non-developers? :)
>> >>
>> >> diff --git a/libiptc/libiptc.c b/libiptc/libiptc.c
>> >> index 42d9784..4106afe 100644
>> >> --- a/libiptc/libiptc.c
>> >> +++ b/libiptc/libiptc.c
>> >> @@ -2730,7 +2730,10 @@ TC_STRERROR(int err)
>> >> { NULL, ENOPROTOOPT, "iptables who? (do you need to insmod?)" },
>> >> { NULL, ENOSYS, "Will be implemented real soon. I promise ;)" },
>> >> { NULL, ENOMEM, "Memory allocation problem" },
>> >> - { NULL, ENOENT, "No chain/target/match by that name" },
>> >> + { NULL, ENOENT, "An object was not found. Check that the chain, "
>> >> + "target/match extension, and/or per-extension "
>> >> + "named object exists. Look at `dmesg` for "
>> >> + "reports about the latter." },
>> >
>> >This makes sense to me.
>> >
>> >We still need better (more fine grain) error reporting though. That's
>> >one limitation that would be great to solve.
>> >
>> >Probably the netlink interface will allow us to solve this.
>>
>> Yes. Did you see my most recent answer yet?:
>> http://marc.info/?l=netfilter-devel&m=132705156805852&w=2
>
>Yes, I read it.
>
>Am I missing anything about it regarding this thread?
Well I then take it you were fine with the series of 7, and will build
only patches on top.
--
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
