From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0AEF1ECDFB3 for ; Mon, 16 Jul 2018 15:34:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B4CA12083E for ; Mon, 16 Jul 2018 15:34:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B4CA12083E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730733AbeGPQB4 (ORCPT ); Mon, 16 Jul 2018 12:01:56 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:60342 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727532AbeGPQB4 (ORCPT ); Mon, 16 Jul 2018 12:01:56 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 882ADD3A; Mon, 16 Jul 2018 15:33:58 +0000 (UTC) Date: Mon, 16 Jul 2018 17:33:56 +0200 From: Greg Kroah-Hartman To: Martijn Coenen Cc: linux-kernel@vger.kernel.org, Masahiro Yamada , Michal Marek , Geert Uytterhoeven , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Alan Stern , Oliver Neukum , Arnd Bergmann , Jessica Yu , Stephen Boyd , Philippe Ombredanne , Kate Stewart , Sam Ravnborg , linux-kbuild@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-usb@vger.kernel.org, usb-storage@lists.one-eyed-alien.net, linux-scsi@vger.kernel.org, linux-arch@vger.kernel.org, maco@google.com, sspatil@google.com, malchev@google.com, joelaf@google.com Subject: Re: [PATCH 0/6] Symbol namespaces Message-ID: <20180716153356.GA8034@kroah.com> References: <20180716122125.175792-1-maco@android.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180716122125.175792-1-maco@android.com> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 16, 2018 at 02:21:19PM +0200, Martijn Coenen wrote: > As of Linux 4.17, there are more than 30000 exported symbols > in the kernel. There seems to be some consensus amongst > kernel devs that the export surface is too large, and hard > to reason about. > > Generally, these symbols fall in one of these categories: > 1) Symbols actually meant for drivers > 2) Symbols that are only exported because functionality is > split over multiple modules, yet they really shouldn't > be used by modules outside of their own subsystem > 3) Symbols really only meant for in-tree use > > When module developers try to upstream their code, it > regularly turns out that they are using exported symbols > that they really shouldn't be using. This problem is even > bigger for drivers that are currently out-of-tree, which > may be using many symbols that they shouldn't be using, > and that break when those symbols are removed or modified. > > This patch allows subsystem maintainers to partition their > exported symbols into separate namespaces, and module > authors to import such namespaces only when needed. > > This allows subsystem maintainers to more easily limit > availability of these namespaced symbols to other parts of > the kernel. It can also be used to partition the set of > exported symbols for documentation purposes; for example, > a set of symbols that is really only used for debugging > could be in a "SUBSYSTEM_DEBUG" namespace. To give people a bit more background here, this is something that both Andi Kleen and I talked about over a decade ago. Martijn based his work on Andi's original patches and made them all work well, something that I was unable to do :) His addition of using the build system to automatically generate a patch for a subsystem based on the symbol namespace changes is frickin amazing. Great work here, this is something that I have wanted for the kernel for a long time. greg k-h