lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ