linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Joe Perches <joe@perches.com>
Cc: linux-mips@linux-mips.org, linux-usb@vger.kernel.org,
	linux-doc@vger.kernel.org, brcm80211-dev-list@broadcom.com,
	linux-kernel@vger.kernel.org, linux-sctp@vger.kernel.org,
	devel@open-fcoe.org, dev@openvswitch.org,
	linux-s390@vger.kernel.org,
	user-mode-linux-devel@lists.sourceforge.net,
	linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org,
	bridge@lists.linux-foundation.org, lvs-devel@vger.kernel.org,
	coreteam@netfilter.org, b43-dev@lists.infradead.org,
	cbe-oss-dev@lists.ozlabs.org, devel@driverdev.osuosl.org,
	wimax@linuxwimax.org, devicetree-discuss@lists.ozlabs.org,
	linux-nfs@vger.kernel.org, netfilter@vger.kernel.org,
	user-mode-linux-user@lists.sourceforge.net,
	linux-arm-kernel@lists.infradead.org,
	davinci-linux-open-source@linux.davincidsp.com,
	linux-parisc@vger.kernel.org, netdev@vger.kernel.org,
	b.a.t.m.a.n@lists.open-mesh.org, linux-wireless@vger.kernel.org,
	users@rt2x00.serialmonkey.com, e1000-devel@lists.sourceforge.net,
	ath9k-devel@lists.ath9k.org, netfilter-devel@vger.kernel.org,
	uclinux-dist-devel@blackfin.uclinux.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH net-next 00/21] treewide: Use consistent api style for address testing
Date: Fri, 19 Oct 2012 09:04:14 +0200	[thread overview]
Message-ID: <1350630254.2293.183.camel@edumazet-glaptop> (raw)
In-Reply-To: <cover.1350618006.git.joe@perches.com>

On Thu, 2012-10-18 at 20:55 -0700, Joe Perches wrote:
> ethernet, ipv4, and ipv6 address testing uses 3 different api naming styles.
> 
> ethernet uses:	is_<foo>_ether_addr
> ipv4 uses:	ipv4_is_<foo>
> ipv6 uses:	ipv6_addr_<foo>
> 
> Standardize on the ipv6 style of <prefix>_addr_<type> to reduce
> the number of styles to remember.
> 
> The new consistent styles are:
> 
> eth_addr_<foo>(const u8 *)
> ipv4_addr_<foo>(__be32)
> ipv6_addr_<foo>(const struct in6_addr *)
> 
> Add temporary backward compatibility #defines for the old names too.
> 
> Joe Perches (21):
>   etherdevice: Rename is_<foo>_ether_addr tests to eth_addr_<foo>
>   net: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
>   arch: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
>   wireless: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
>   drivers: net: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
>   staging: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
>   infiniband: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
>   scsi: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
>   of: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
>   s390: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
>   usb: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
>   uwb: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
>   Documentation: networking: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
>   llc_if.h: Convert is_<foo>_ether_addr uses to eth_addr_<foo>
>   in.h: Rename ipv4_is_<foo> functions to ipv4_addr_<foo>
>   net: Convert ipv4_is_<foo> uses to ipv4_addr_<foo>
>   infiniband: Convert ipv4_is_<foo> uses to ipv4_addr_<foo>
>   ath6kl: Convert ipv4_is_<foo> uses to ipv4_addr_<foo>
>   parisc: Convert ipv4_is_<foo> uses to ipv4_addr_<foo>
>   lockd: Convert ipv4_is_<foo> uses to ipv4_addr_<foo>
>   sctp: Convert ipv4_is_<foo> uses to ipv4_addr_<foo>

Yes they are some names discrepancies, thats a big deal.

And we have alloc_skb() / kfree_skb() / skb_clone() 

Why not skb_alloc() / skb_free() / skb_clone() ?

Some people actually know current code by name of functions, they dont
want to change their mind and having to grep include files and git log
to learn the new names of an old function, especially when traveling and
using a laptop.

Sure, when we want to use eth_random_addr(), a grep into include files
to check if its still the right name (old one was random_ether_addr())
is OK because we dont use this one often.

If you think about it, eth_random_addr() was not the perfect name.

Think about all the documentation you can find outside of kernel tree,
RFC and things like that, copy/pasting some linux kernel code.

This kind of changes make our life more difficult, when we have to
backport patches or rebase code, or even perform some searches to find
prior issues/discussions.

Life of a kernel developer is not only dealing with latest Linus (or
-next) tree, and using automatic 'tools'.

Thats a real pain for me at least.

  reply	other threads:[~2012-10-19  7:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-19  3:55 [PATCH net-next 00/21] treewide: Use consistent api style for address testing Joe Perches
2012-10-19  7:04 ` Eric Dumazet [this message]
2012-10-19 15:55   ` [ath9k-devel] " Pavel Roskin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1350630254.2293.183.camel@edumazet-glaptop \
    --to=eric.dumazet@gmail.com \
    --cc=ath9k-devel@lists.ath9k.org \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=b43-dev@lists.infradead.org \
    --cc=brcm80211-dev-list@broadcom.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=cbe-oss-dev@lists.ozlabs.org \
    --cc=coreteam@netfilter.org \
    --cc=davinci-linux-open-source@linux.davincidsp.com \
    --cc=dev@openvswitch.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=devel@open-fcoe.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=joe@perches.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lvs-devel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=netfilter@vger.kernel.org \
    --cc=uclinux-dist-devel@blackfin.uclinux.org \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    --cc=user-mode-linux-user@lists.sourceforge.net \
    --cc=users@rt2x00.serialmonkey.com \
    --cc=wimax@linuxwimax.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).