Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp3122013ybg; Thu, 24 Oct 2019 22:31:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqweESrozd9zPL2GUWGTr6CBpLO83zHNArMWaGYOIOxSQzsVVl3mY8hWUE31GwwXx819XG7a X-Received: by 2002:a50:af22:: with SMTP id g31mr1881295edd.199.1571981516194; Thu, 24 Oct 2019 22:31:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571981516; cv=none; d=google.com; s=arc-20160816; b=ZphCjv0QVPTcI/yr4n3b08kLKyd+hCb5aYw6iO/1fsAoRniR4b3Wrb500mCcG6ZylF aNp4Oq4AATb9UfD5MqUlT4+P7IPQDSPfyk/WvtJzPDwr7KGnsZyiRMDE47L3Zk7SXlFi xMZTQWuIjCFu+aBpurAxBabG/PczU0j5vqzaoFpyDVH9PLZIP0UN/e2KXxc0kHBwXxlK d70yMV8YWF3DMa1iTqzp8EiLjM9V3676sl97Y8QuWzD/FQOstomGli0ZKD7KU73G2AVa TXHfULRVN4gY5y2NFW8xYDj00isEPWaNfd1KSXelFferth7p3boXtQWgYlWTilZefekL PE0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=kmED9H3HhgwVVQ86s12b9wU01cqR0QgzFhbCOFHeClU=; b=L90kT2argl6M653Z7Njc4nXhOhSlcmwMSDQN8Io7Co7DzVVO58nAKGNu12Ak/ep7sK NX3CSwJJ0VggR9e6ddlAS4+obYg/J9RqVJ/ESC79njiaC4ulcz+3c1AOBwQ8nQ2sEgne 1m2sC6OX4Sh8i1QLWpbyPhbw+dI2qUc/k6fP4ZQDK48ftevPEHwlCGZXJ2JWsgAGdi8B ChA3C6k/Ys0DEgKtnpITqBqt8z9nPG8Pype/SKuM3BIQ5purDUpvbOHNLu3e4tA22PoR flu6IoIwsownUUXHCrdwiRGxUh6ujGsJN/HIvoTLflWY5TC6NrNx8LsRbeXPuH7QgdOH RU8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=S1mM97qM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p92si566762edd.407.2019.10.24.22.31.32; Thu, 24 Oct 2019 22:31:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=S1mM97qM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2408906AbfJXJfv (ORCPT + 99 others); Thu, 24 Oct 2019 05:35:51 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:33169 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2408901AbfJXJfv (ORCPT ); Thu, 24 Oct 2019 05:35:51 -0400 Received: by mail-wr1-f68.google.com with SMTP id s1so16499950wro.0 for ; Thu, 24 Oct 2019 02:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=kmED9H3HhgwVVQ86s12b9wU01cqR0QgzFhbCOFHeClU=; b=S1mM97qME0Ixk73g4LGqcCagCBx33p9xYc6nmNo95xpmoy4pywt5jOn1AOzctxPT0N nB8+li9SpYltwU9/B58VVKFmqClfis9qWSOprXtc6VB6a9Puf83HLXQkNBet/h33yqAR WVArAD+EZt2+aaggCpxWLw+3LbCroUBv86+xfu3mB6539VfCotaYfsEgnnCDrmW5n5+E XHbqIRWbvT+T7Np7UUuoTXPX8BPuLV6v0uHCj35eGdrCSPzSfzUz9Eo49WkDWFFsqcgS vLpKsOhAAQstb+gTrd/fpMaJDfK81gR6ltUBmaTVsSQ0P+GSWyVj3T4N0+tHa5V2Pqnh 9SFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=kmED9H3HhgwVVQ86s12b9wU01cqR0QgzFhbCOFHeClU=; b=HwEtMBeaVTORrQqbXeBxfglbCOPBxlgtertvEIGhN0YC24F9D1pCUISLPcSJCWuL4A PaH71luBJbKeq5W/l5Ugc2U9iq2fNenltnK6giqEDDqhSR3i1gt0xVWd3UHXd16rPL+n hsGDDXip13eZrBgHARzeJKqEB2xFG45UDz2W1HKyxYF6iuFFrwrlkGjjAx+8MdVHMPtD lMHlAmSoXVnRSmgZGhyN7QUwrOEa1jNfQnahEGkFXPudFXWKiiplX67PO4zgynbFC8hs vydfbxl0XIpc+/FL6r6h0+fa6mnoc57V1wGkX/1rHXlbN50+5GsICmRBOMK+PcoSZ/Dq GQeQ== X-Gm-Message-State: APjAAAVVOq3bxeAXgdn1AT+iWvA41dsBmeNVF2VOkywJ2yy1dyBWocCf 12xHeu57F7eLA5Am6xZULi3pJw== X-Received: by 2002:a5d:630f:: with SMTP id i15mr2972442wru.226.1571909747667; Thu, 24 Oct 2019 02:35:47 -0700 (PDT) Received: from google.com ([2a00:79e0:d:210:e8f7:125b:61e9:733d]) by smtp.gmail.com with ESMTPSA id i18sm22647040wrx.14.2019.10.24.02.35.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Oct 2019 02:35:47 -0700 (PDT) Date: Thu, 24 Oct 2019 10:35:46 +0100 From: Matthias Maennich To: Luis Chamberlain Cc: linux-kernel@vger.kernel.org, kernel-team@android.com, Jessica Yu , Masahiro Yamada , Martijn Coenen , Lucas De Marchi , Shaun Ruffell , Greg Kroah-Hartman , Will Deacon , linux-kbuild@vger.kernel.org, linux-modules@vger.kernel.org Subject: Re: [PATCH v2 0/4] export/modpost: avoid renaming __ksymtab entries for symbol namespaces Message-ID: <20191024093546.GB199239@google.com> References: <20191010151443.7399-1-maennich@google.com> <20191018093143.15997-1-maennich@google.com> <20191023122222.GA27861@42.do-not-panic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20191023122222.GA27861@42.do-not-panic.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 23, 2019 at 12:22:22PM +0000, Luis Chamberlain wrote: >On Fri, Oct 18, 2019 at 10:31:39AM +0100, Matthias Maennich wrote: >> The introduction of the symbol namespace patches changed the way symbols are >> named in the ksymtab entries. That caused userland tools to fail (such as >> kmod's depmod). As depmod is used as part of the kernel build it was worth >> having another look whether this name change can be avoided. > >Why have this as a default feature? What about having an option to >disable this feature? The benefit being that without a full swing of >tests to avoid regressions its not clear what other issues may creep >up. With this as optional, those wanting the mechanism can enable it >and happilly find the issues for those more conservative. The strongest argument against that is, that the 'conservative' people would constantly break things for the more 'adventurous' ones. They would introduce namespace requirements by just using symbols without correctly adjusting the imports. Second, vmlinux and modules would have to be compiled in the same configuration. Otherwise they are incompatible and we would likely have to maintain code in the module loader to catch issues caused by that. In general, I think for the adoption of this feature and one of its purposes - making unexpected use of symbols across the tree visible already at review time - we should not make this an optional one. Enforcing the imports at module load time is optional (there is an option). And finally, having that code configurable for both options introduces quite some complexity in kernel/module.c, modpost and include/linux/export.h that would make the code hard to maintain and complex to test. Hence that would likely introduce more issues. I know the feature came with some rough edges. Sorry about that. I think, we got most of them worked out pretty well (big thanks to Masahiro and Jessica and others helping with that). Now the actual change to the surface exposed to userland tools is much smaller and the feature itself less intrusive. Cheers, Matthias > > Luis