On Monday 2011-02-07 21:50, James Nurmi wrote: >> +--------+-------------------+---------------+-----------------+--------------------------------------+ >> |    Â| NFXTA_ERRSTR   Â|  char []   | NLA_NUL_STRING Â| Arbitrary              Â| >> +--------+-------------------+---------------+-----------------+--------------------------------------+ > >W/r/t the NUL_STRING's -- is there a good reason to use a NUL'd >strings for NAME/etc, given the length is known? Simpler to deal with string functions especially when it comes to strcmp. >> 5 Message types >> ... > >My biggest concern here seems as already pointed out -- the use of >STOP && deep nesting in messages; Every time a STOP occurs in an >internal message, it's semantically equivalent to the completion of an >NF_F_MULTI no? MULTIs do not seem to be nestable. >I see the advantage of a trivial protocol, but wouldn't it be much >simpler to have a 'bigger' protocol (table/chain/rule) with an >optional ATOMIC guarantee? I have no idea what you could mean by that. (In fact, most of your reply gave me nothing to act on.) >I don't see anywhere else guaranteeing tables/matches/rules will be >managed (as a set) with atomicity [I'm probably wrong], so doing it in >the protocol feels awkward. By issuing NFXTM_TABLE_REPLACE (atomic replace of table) or NFXTM_CHAIN_SPLICE (atomic replace of a chain and its rules), rules that follow are collected and implanted into the live ruleset on the final NFXTM_STOP. And these two cover all the atomicity one would need as I see it. -- 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
