> -----Original Message----- > From: Pablo Neira Ayuso [mailto:pablo@xxxxxxxxxxxxx] > On Fri, Mar 31, 2017 at 06:38:20PM +0800, gfree.wind@xxxxxxxxxxx wrote: > > +static struct nf_ct_nat_helper pptp_nat = { > > + .name = "pptp_nat", > > Why all these with "xyz_nat" names? I just used the variable name before. How about rename it to "xyz_nat_helper"? > > This is going to break ctnetlink, as this is the name that identifies the NAT > helper to be used. > > > + .expectfn = pptp_expectfn, > > +}; > > + > > static void pptp_expectfn(struct nf_conn *ct, > > struct nf_conntrack_expect *exp) > > { > > @@ -221,7 +229,7 @@ static int exp_gre(struct nf_conn *ct, __be16 callid, > __be16 peer_callid) > > &ct->tuplehash[dir].tuple.src.u3, > > &ct->tuplehash[dir].tuple.dst.u3, > > IPPROTO_GRE, &peer_callid, &callid); > > - exp_orig->expectfn = pptp_expectfn; > > + exp_orig->nat_helper = &pptp_nat; > > > > /* reply direction, PAC->PNS */ > > dir = IP_CT_DIR_REPLY; > > @@ -230,7 +238,7 @@ static int exp_gre(struct nf_conn *ct, __be16 callid, > __be16 peer_callid) > > &ct->tuplehash[dir].tuple.src.u3, > > &ct->tuplehash[dir].tuple.dst.u3, > > IPPROTO_GRE, &callid, &peer_callid); > > - exp_reply->expectfn = pptp_expectfn; > > + exp_reply->nat_helper = &pptp_nat; > > Why do we need to attach nat_helper instead of expectfn? I would prefer we > do not. Because we need to introduce another member "expectfn_module" in the third patch. If insisted on the current style, the codes would look like the following: exp_reply->expectfn = pptp_expectfn; exp_reply->expectfn_module = THIS_MODULE; There are two assignments when using expect_fn. It isn't only a little duplicated, but also it is easy to lost the module assignment and bring one bug. If attached the nat_helper instead of expectfn, there would be only one assignment. Regards Feng -- 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
