[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <OF204908E6.65D34E4B-ON85257B41.00463F2F-85257B41.0048A60B@us.ibm.com>
Date: Tue, 2 Apr 2013 09:13:35 -0400
From: David Stevens <dlstevens@...ibm.com>
To: Cong Wang <amwang@...hat.com>
Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
netdev-owner@...r.kernel.org, stephen@...workplumber.org
Subject: Re: [Patch net-next v1 3/4] vxlan: add ipv6 support
Cong Wang <amwang@...hat.com> wrote on 04/01/2013 09:46:43 PM:
> Well, besides avoid redefining another type, what else could we gain by
> using sockaddr_in6?
The gain is code readability. If you have a type that's
already defined and used throughout the network code, someone
trying to understand your code won't need to look up the type
and details to figure it out and modify it.
> Look, we would have "vip->vip_sin.sin_addr.s_addr" instead of
> "ipa->ip4", much longer than the current one...
>
> So why defining a shorter and less complex struct matters?
>
>
Because you have entire sections of nearly duplicated
code that handle IPv4 alone or IPv6 alone. That's a maintenance
issue over time because future changes need to happen in 2
separate places and are more likely to be missed in one or
not replicated identically.
Using sockaddrs, the field containing an address is
the same (e.g., "gaddr" or "dst") whether it is v4 or v6
because the structure self-identifies the address format
by the address family. So, you can have common code for
either address family -- "vxlan->gaddr = group;" or similar--
and you only have family-specific code where there is a
difference between the families.
VXLAN is an in-kernel client and server and like its
user-space counterparts, you can write a v4-only implementation
and a v6-only implementation separately, or you can use common code
for both with generic addresses. Using common code is usually
easier to understand, modify and debug.
+-DLS
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists