| 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
| ||
|
Message-ID: <20101014214426.GA9236@windriver.com> Date: Thu, 14 Oct 2010 17:44:27 -0400 From: Paul Gortmaker <paul.gortmaker@...driver.com> To: Stephen Hemminger <shemminger@...tta.com> Cc: Neil Horman <nhorman@...driver.com>, David Miller <davem@...emloft.net>, netdev@...r.kernel.org, allan.stephens@...driver.com, Jon Maloy <jon.maloy@...csson.com> Subject: Re: [PATCH net-next] tipc: cleanup function namespace [Re: [PATCH net-next] tipc: cleanup function namespace] On 14/10/2010 (Thu 11:33) Stephen Hemminger wrote: > On Thu, 14 Oct 2010 13:53:21 -0400 > Paul Gortmaker <paul.gortmaker@...driver.com> wrote: > > > 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@...driver.com> > > How about putting an entry in feature-removal.txt with a short (6 month) > window? I'm fine with that too. P. >From 5a15a26de63a29fcb6cb7a7fb83b6d2fc63cbadb Mon Sep 17 00:00:00 2001 From: Paul Gortmaker <paul.gortmaker@...driver.com> Date: Thu, 14 Oct 2010 17:29:08 -0400 Subject: [PATCH] TIPC: Document the demise of the Native API for March 2011 The native API in the TIPC code exists as a bunch of functions and exported symbols that aren't actually used by any currently in-tree kernel code/modules. Since this code is anomalous to the general guiding principle that the kernel should not be libc, coverage tools and people intending to do general cleanups keep finding this code and suggesting that it be removed. It seems the right thing to do is to just finally delete it once and for all, after giving a reasonable window for any existing users to find alternative solutions to their custom use case(s). Signed-off-by: Paul Gortmaker <paul.gortmaker@...driver.com> --- Documentation/feature-removal-schedule.txt | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index f456389..1def37e 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -573,3 +573,15 @@ Why: Hareware scan is the prefer method for iwlwifi devices for Who: Wey-Yi Guy <wey-yi.w.guy@...el.com> ---------------------------- + +What: TIPC: Delete all code and exported symbols specific to Native API +When: March 2011 +Why: The TIPC Native API, as described here: + http://tipc.sourceforge.net/doc/tipc_1.7_prog_guide.html#native_api + is implemented by exporting a bunch of otherwise unused functions + for possible modular linkage by custom end-user code. This goes + against the general concept that the kernel should not be libc. + +Who: Paul Gortmaker <paul.gortmaker@...driver.com> + +---------------------------- -- 1.7.2.1 -- 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