netdev - Re: [Patch net-next v3 0/9] net: introduce generic type and helpers for IP address

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20130820.231159.2092592990953992941.davem@davemloft.net>
Date:	Tue, 20 Aug 2013 23:11:59 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	amwang@...hat.com
Cc:	netdev@...r.kernel.org
Subject: Re: [Patch net-next v3 0/9] net: introduce generic type and
 helpers for IP address

From: Cong Wang <amwang@...hat.com>
Date: Mon, 19 Aug 2013 18:14:29 +0800

> From: Cong Wang <amwang@...hat.com>
> 
> As IPv6 becomes popular, more and more subsystems begin to support IPv6,
> therefore we need a generic IP address type, in case of duplicates.
> Also we will also need some helpers to compare, print, check the generic
> IP address.
> 
> This patchset introduce a new type union inet_addr as a union of IPv4
> and IPv6 address, and struct in_addr_gen for inetpeer and bridge mdb,
> plus some helper functions that will be used by existing code and
> in the future VXLAN module.
> 
> However, due to ABI limit, we still can't convert union nf_inet_addr
> to union inet_addr.
> 
> Signed-off-by: Cong Wang <amwang@...hat.com>

I still don't want to apply this patch series, and very honestly my
patience is running very thin.

Netconsole and netpoll do not need the family field, and they
absolutely do not need the port field that a sockaddr_in et
al. provide.

So you have to get rid of it, and do the same simplification
everywhere.  So I don't have to tell you to do it again when
you resubmit this stuff and the next patch I get to has the
same exact problem.

If this patch series doesn't converge upon adding absolutely zero
overhead where it isn't needed I'm just going to auto-reject these
patches when you post them, that's how frustrated I am with this
stuff.

If in the process of commonizing you add stuff where it isn't needed
then you're doing it wrong.

That's why all these places use a different data structure!  They have
different needs.  Can you see that?

--
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