In article <42182082.9060301@xxxxxxxxx> (at Sun, 20 Feb 2005 06:30:42 +0100),
Patrick McHardy <kaber@xxxxxxxxx> says:
> Herbert Xu wrote:
>
> > I know this comment is probably a bit late but why didn't we simply put
> > type/code into sport/dport in struct flowi instead of introducing the
> > monstrosities of xfrm_flowi_sport/xfrm_flowi_dport?
> >
> > Something like
> >
> > struct {
> > __u16 type;
> > __u16 code;
> > } icmpt;
> >
> > would've done (and still would do) the trick, no?
>
> Here is an updated patch that kills xfrm_flowi_{sport,dport}.
> I've checked around, there seems to be nothing that relies
> on type and code beeing u8.
I didn't this because there are several places which depend on u8.
If we go this way, we need to fix other places as well. e.g.
net/ipv4/raw.c:raw_probe_proto_opt()
net/ipv4/xfrm4_policy.c:_decode_session4()
net/ipv6/raw.c:rawv6_probe_proto_opt()
net/ipv6/netfilter/ip6t_REJECT.c:send_unreach()
net/ipv6/xfrm6_policy.c:_decode_session6()
net/ipv6/ndisc.c:ndisc_flow_init()
net/ipv6/icmp.c:icmpv6_send()
net/ipv6/icmp.c:icmpv6_echo_reply()
(Note that type and code are stored in network-byte order.)
--yoshfuji
|