From: Paul Gortmaker <paul.gortmaker@windriver•com>
To: Neil Horman <nhorman@tuxdriver•com>
Cc: Stephen Hemminger <shemminger@vyatta•com>,
David Miller <davem@davemloft•net>,
netdev@vger•kernel.org, allan.stephens@windriver•com,
Jon Maloy <jon.maloy@ericsson•com>
Subject: Re: [PATCH net-next] tipc: cleanup function namespace
Date: Thu, 14 Oct 2010 13:53:21 -0400 [thread overview]
Message-ID: <4CB74391.9020400@windriver.com> (raw)
In-Reply-To: <20101014012951.GA2186@localhost.localdomain>
On 10-10-13 09:29 PM, Neil Horman wrote:
> On Wed, Oct 13, 2010 at 08:23:24PM -0400, Paul Gortmaker wrote:
>> On 10-10-13 07:20 PM, Stephen Hemminger wrote:
>>> Do some cleanups of TIPC based on make namespacecheck
>>> 1. Don't export unused symbols
>>> 2. Eliminate dead code
>>> 3. Make functions and variables local
>>> 4. Rename buf_acquire to tipc_buf_acquire since it is used in several files
>>>
>>> Compile tested only.
>>> This make break out of tree kernel modules that depend on TIPC routines.
>>
>> Hi Stephen,
>>
>> When I first started looking at TIPC code, I too came to the
>> same conclusion as you did and was about to do #1,2,3 -- but
>> then I was told that the exported symbols were part of an API
>> and might be in use by folks here and there as per this thread:
>>
>> http://www.mail-archive.com/netdev@vger.kernel.org/msg30208.html
>>
> I think its telling the the argument in the above thread for keeping the API
> were that users of it were out there and 'likely to contribute' in the future.
> That thread was 3 years ago. They might be using the API from outside the
> kernel tree, but they're not planning on contributing. As Christoph noted,
> they're freeloaders. The community really doesn't need or want to maintain an
> API like that. If these users are your customers, and removing the API is
> unacceptable, perhaps its time to move the entire TIPC module out of tree.
As I'd said -- I don't know what the use cases of these API users are,
and so as far as I know they aren't customers either. For what it is
worth, know that I personally wouldn't try and use a business case to
justify a technically wrong decision here on netdev anyway.
I was just describing the history of the situation, and suggesting
one possible slower approach of phasing it out as a courtesy to those
users, in the same way that the kernel community has extended that
same courtesy with other things in feature-removal.txt
In the end, since Jon is OK with the removal, and is in the process of
communicating this to the API users he is aware of, I sure don't have
any reason to try and save the API. If folks are good with having it
just go away overnight, then great -- I'll be just as happy to see it
disappear as you and Stephen. So, a long winded way of saying...
Acked-by: Paul Gortmaker <paul.gortmaker@windriver•com>
Paul.
>
> Neil
>
next prev parent reply other threads:[~2010-10-14 17:53 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-13 0:25 [PATCH net-next 1/5] tipc: Enhance enabling and disabling of Ethernet bearers Paul Gortmaker
2010-10-13 0:25 ` [PATCH net-next 2/5] tipc: Simplify bearer shutdown logic Paul Gortmaker
2010-10-13 14:39 ` Neil Horman
2010-10-14 23:58 ` Paul Gortmaker
2010-10-15 10:48 ` Neil Horman
2010-10-13 0:25 ` [PATCH net-next 3/5] tipc: Optimizations to bearer enabling logic Paul Gortmaker
2010-10-13 14:58 ` Neil Horman
2010-10-15 1:11 ` Paul Gortmaker
2010-10-15 11:00 ` Neil Horman
2010-10-15 21:31 ` Paul Gortmaker
2010-10-18 10:50 ` Neil Horman
2010-10-18 21:43 ` Paul Gortmaker
2010-10-18 23:59 ` Neil Horman
2010-10-21 11:31 ` David Miller
2010-10-13 0:25 ` [PATCH net-next 4/5] tipc: Rework data structures that track neighboring nodes and links Paul Gortmaker
2010-10-13 16:24 ` Neil Horman
2010-10-13 0:25 ` [PATCH net-next 5/5] tipc: clean out all instances of #if 0'd unused code Paul Gortmaker
2010-10-13 16:26 ` Neil Horman
2010-10-13 17:08 ` Paul Gortmaker
2010-10-13 17:23 ` Neil Horman
2010-10-13 21:28 ` David Miller
2010-10-13 23:20 ` [PATCH net-next] tipc: cleanup function namespace Stephen Hemminger
2010-10-14 0:23 ` Paul Gortmaker
2010-10-14 0:32 ` Stephen Hemminger
2010-10-14 1:29 ` Neil Horman
2010-10-14 17:53 ` Paul Gortmaker [this message]
2010-10-14 18:33 ` Stephen Hemminger
2010-10-14 19:49 ` Jon Maloy
2010-10-14 21:44 ` Paul Gortmaker
2010-10-14 22:13 ` Stephen Hemminger
2010-10-15 11:01 ` Neil Horman
2010-10-15 16:59 ` Jon Maloy
2010-10-14 13:31 ` Jon Maloy
2010-10-16 18:56 ` David Miller
2010-10-13 13:42 ` [PATCH net-next 1/5] tipc: Enhance enabling and disabling of Ethernet bearers Neil Horman
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=4CB74391.9020400@windriver.com \
--to=paul.gortmaker@windriver$(echo .)com \
--cc=allan.stephens@windriver$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=jon.maloy@ericsson$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=nhorman@tuxdriver$(echo .)com \
--cc=shemminger@vyatta$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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