Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp3382205ybn; Fri, 27 Sep 2019 05:39:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqwpE+TFd8nvxqGbj6nJt23aaWCINaZOOb/j7r4XDBNqiasXlO0FNuc/ZbRbuFeir4tKCYat X-Received: by 2002:a50:9e0a:: with SMTP id z10mr4284974ede.202.1569587954231; Fri, 27 Sep 2019 05:39:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569587954; cv=none; d=google.com; s=arc-20160816; b=AzvVXrw8XMGL8yugbduTq29HnVIz9EqkxtWxIkjo3KPBjnxlTcU5RnD/0BF36bKImC oq9XpUc27J8kHXCV64Vtzj28rBWa842u/etR850QoDBCr17fKwzfYKCSO6eRVi6a4fLK tYz/HoAQbLFZDfsqxKAi39d69hyzhT1CZuu53FK8jqqjpcSdJXhUyrGZgTmrvXVZ26Lx pRMdBFA84PG140kUcssIw8cCPkyqLCmFu3MVDqndRKEB7XeXdft1ChYSAO0cTF7icvIs Rzvg3ABVl7C/RUuup2db1x9hOMDKY0fIZNbMKpEk34AimtiQoavp0syKfP9riDRhema/ vzvg== 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=VRuu/jOQ4Zp+zYJZfIF9hFDwWbv4EjPC9iKOvfai/Ug=; b=MdJdHQa+xhOmM/p1n4XkRsesLD8xQ6bnSywYBxR9zJRL/Qz+JyxauycZy3aDZGt0L0 1tJwJE34/42rVzk3A6+iR2JGFbWtmJhHsH++J8nFgEFpwZKDyog9Xugi9cLffyGk58Bh ra68Zj6BG1gPxjJNv7k3BzMaKLGFkwgIyuO8mW7csGb4ekiOTHpLyjUMIsYsFomat9DI 5xB0xN77cH1p6dDSTErQ/ovSwYU1SCZujKkOga01h/OhZGSa36ITh0gbEkXjzspBJoUG yNCrX+WRuOYDsHfa+aci0AV+kQdV4a+snpEsym5RAJ3m9zjomeENrVmuMU6xi5WbWF8p n/kg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ujDS9k2O; 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 w2si1537480edc.386.2019.09.27.05.38.50; Fri, 27 Sep 2019 05:39:14 -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=ujDS9k2O; 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 S1726441AbfI0MgW (ORCPT + 99 others); Fri, 27 Sep 2019 08:36:22 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:45018 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725890AbfI0MgW (ORCPT ); Fri, 27 Sep 2019 08:36:22 -0400 Received: by mail-wr1-f66.google.com with SMTP id i18so2518471wru.11 for ; Fri, 27 Sep 2019 05:36:18 -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=VRuu/jOQ4Zp+zYJZfIF9hFDwWbv4EjPC9iKOvfai/Ug=; b=ujDS9k2OFc0WreqK2y/fe3R6tAVOaH4UfeF+TiT42v8swDKFwVKCk6zo4b9m6X2ZT3 oSCGFDePMAAvuxW/GcldxxlJNycLBYIKPzBg5kyUBHv5TAg4ydQJM5TGuDGiXigA1AOD zPOmFNnzjOL2vDIMvtZIty3Uoq1A3Al6TZ75BjLi91HdQIPMOlf0l6EHW6MjwxftMhq9 S0W5MQPBlcFgCSpub7F21j9+GhnXqS9sLn3TEpPuBpAqCqhmJ9Tl3vgzGn8c6Z7Y1Ctk kwP/lIrLn1T3o1A7/a0SeLZ4v2XrOLsg7VG1UZZs6I5tLFLaGR8cbBmMZ/l/zt9ecSBM 9UWg== 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=VRuu/jOQ4Zp+zYJZfIF9hFDwWbv4EjPC9iKOvfai/Ug=; b=cxFADLIrH3bPuUB86mj+sapK6zzJJFnJVjmjA99Z1Cc4Iup2E3G4r+ztrWMiMUfA64 +GyvB81cIX/TvJngwWGKvK+MAQ6aXhqdZmWzSgqqrQk4gQ68aOMKokGwL4NI/jeVUxZK b67RVHAGUD/GYZiAknfoqzHg2NkeKjgyHSiGsHRNpe9JOHsJkZBZ00U8nS2cinEyxU7S N7+huOyTqsc7TBMzOAiuWjqWeuGWcrC7LNR6/RnU5/fb5c0eMEijbqn0ZKV/WmUahDuG GALUpSJ0VHEW1mgW1dXqKbaYByKviUsxq4EoUmefUy1fjn4qqXO+aO2eWtNLx8ZDnz+2 qtMA== X-Gm-Message-State: APjAAAWgLOP5hQpP3lBNmnm7aBV2QsMIpaLfiDWwZfIHOzZT61dcQXJo BOX5TTIlzXU1Ee4WgR5Sae9v5g== X-Received: by 2002:a05:6000:14b:: with SMTP id r11mr2584070wrx.58.1569587777681; Fri, 27 Sep 2019 05:36:17 -0700 (PDT) Received: from google.com ([2a00:79e0:d:210:e8f7:125b:61e9:733d]) by smtp.gmail.com with ESMTPSA id d9sm4077030wrc.44.2019.09.27.05.36.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Sep 2019 05:36:16 -0700 (PDT) Date: Fri, 27 Sep 2019 13:36:13 +0100 From: Matthias Maennich To: Rasmus Villemoes Cc: Masahiro Yamada , Jessica Yu , Greg Kroah-Hartman , Joel Fernandes , Martijn Coenen , Will Deacon , Will Deacon , linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/7] module: avoid code duplication in include/linux/export.h Message-ID: <20190927123613.GD259443@google.com> References: <20190927093603.9140-1-yamada.masahiro@socionext.com> <20190927093603.9140-5-yamada.masahiro@socionext.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: 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 Fri, Sep 27, 2019 at 01:07:33PM +0200, Rasmus Villemoes wrote: >On 27/09/2019 11.36, Masahiro Yamada wrote: >> include/linux/export.h has lots of code duplication between >> EXPORT_SYMBOL and EXPORT_SYMBOL_NS. >> >> To improve the maintainability and readability, unify the >> implementation. >> >> When the symbol has no namespace, pass the empty string "" to >> the 'ns' parameter. >> >> The drawback of this change is, it grows the code size. >> When the symbol has no namespace, sym->namespace was previously >> NULL, but it is now am empty string "". So, it increases 1 byte >> for every no namespace EXPORT_SYMBOL. >> >> A typical kernel configuration has 10K exported symbols, so it >> increases 10KB in rough estimation. >> >> I did not come up with a good idea to refactor it without increasing >> the code size. > >Can't we put the "aMS" flags on the __ksymtab_strings section? That >would make the empty strings free, and would also deduplicate the >USB_STORAGE string. And while almost per definition we don't have exact >duplicates among the names of exported symbols, we might have both a foo >and __foo, so that could save even more. I was not aware of this possibility and I was a bit bothered that I was not able to deduplicate the namespace strings in the PREL case. So, at least I tried to avoid having the redundant empty strings in it. If this approach solves the deduplication problem _and_ reduces the complexity of the code, I am very much for it. I will only be able to look into this next week. >I don't know if we have it already, but we'd need each arch to tell us >what symbol to use for @ in @progbits (e.g. % for arm). It seems most >are fine with @, so maybe a generic version could be > >#ifndef ARCH_SECTION_TYPE_CHAR >#define ARCH_SECTION_TYPE_CHAR "@" >#endif > >and then it would be >section("__ksymtab_strings,\"aMS\","ARCH_SECTION_TYPE_CHAR"progbits,1") > >But I don't know if any tooling relies on the strings not being >deduplicated. Matthias Cheers, >Rasmus