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=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 4F60EC433F5 for ; Thu, 9 Sep 2021 10:03:24 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 00260611AF for ; Thu, 9 Sep 2021 10:03:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 00260611AF Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.182933.330797 (Exim 4.92) (envelope-from ) id 1mOGtk-0002C5-LN; Thu, 09 Sep 2021 10:03:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 182933.330797; Thu, 09 Sep 2021 10:03:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mOGtk-0002By-IX; Thu, 09 Sep 2021 10:03:12 +0000 Received: by outflank-mailman (input) for mailman id 182933; Thu, 09 Sep 2021 10:03:11 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mOGtj-0002Bo-KF for xen-devel@lists.xenproject.org; Thu, 09 Sep 2021 10:03:11 +0000 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 230f70c2-1155-11ec-b1ab-12813bfff9fa; Thu, 09 Sep 2021 10:03:10 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 230f70c2-1155-11ec-b1ab-12813bfff9fa DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1631181790; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=IeINUvl4C5/dwCvB0P3GDK7VX2gf3en260aSHwb3l2s=; b=RQOkfmaGf2jS9OC3w/3NvDqOTl2vKW/hRYkdkq+hv4uKL0cJRqIHVQtk Tg2aYw6Bn4ELBDqBszlKiw7b2ZVYlEVYqb/5G/Jxk/Qn5J182lFc49Iw/ PANkind510sybwER+lSU/ZCJc1POlP2JSLlvAgJxSGE82KNJO0xREYCpg A=; Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Beew7uxmj13Bf6E7BNydK8vV6TYcJqe4lFR7RgGL6M1GtVcvhQO1/klaiR+xBrIiW/OaB699zQ 4Tpbx1mFQx4axiKrz4ijccBj3bCBmH2UWj5+5ErYZbj4J+GC2OmQZMsCccvC+G+PF6xdrkOpw7 7IVpTFS8J3deaF9bfg7vA1a2HeOISzqTuBfn7uBeaesg2UbUkE0rSWm/qMzeECPjPBmhY7x0qE tFWw3outJTEQzSF5GBKhGC0UJb8HmPWG0f0moEFqEQpxcNVNl7/wivYUHpIpjcY5p30qxMrFYc mFUw8KV5KShNbMUSvXGgjRZa X-SBRS: 5.1 X-MesageID: 52326854 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.156.83 X-Policy: $RELAYED IronPort-HdrOrdr: A9a23:dlFoSaHOfsfhSQjwpLqE6seALOsnbusQ8zAXP0AYc31om+ij5q eTdZUgpHvJYVkqNE3I9eruBEDEewK7yXcX2/h1AV7BZniEhILAFugLhuGO/9SjIVydygc079 YYT0EUMr3N5DZB4/rH3A== X-IronPort-AV: E=Sophos;i="5.85,279,1624334400"; d="scan'208";a="52326854" Date: Thu, 9 Sep 2021 11:03:04 +0100 From: Anthony PERARD To: Jan Beulich CC: Andrew Cooper , George Dunlap , Ian Jackson , Julien Grall , Stefano Stabellini , Wei Liu , Roger Pau =?iso-8859-1?Q?Monn=E9?= , "Tim Deegan" , Subject: Re: [XEN PATCH v7 05/51] x86/mm: avoid building multiple .o from a single .c file Message-ID: References: <20210824105038.1257926-1-anthony.perard@citrix.com> <20210824105038.1257926-6-anthony.perard@citrix.com> <27874b1a-70cb-e647-d271-93ef12dc40dc@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <27874b1a-70cb-e647-d271-93ef12dc40dc@suse.com> On Wed, Sep 08, 2021 at 02:01:43PM +0200, Jan Beulich wrote: > On 08.09.2021 13:14, Anthony PERARD wrote: > > What kind of issue is there with those tiny source files? > > To me they're ugly and their presence is at least mildly confusing. > And apparently I'm not the only one thinking that way, or else such > tiny stubs would have been put there right when introducing these > multiply built sources. Well, at the time when this was introduced, tools/symbols didn't exist, so avoiding the stubs might have been ok by then, but it meant to duplicated %.o:%.c rules in the Makefile... Now, we have tools/symbols, a hack put into the source file to add a ".file instruction", a heuristic in tools/symbols to pick up the ".file" we want, and a workaround to change in behavior of binutils. This is a lot of complexity to avoid introducing those extra source files... complexity that were needed to by added _after_ the initial introduction of multiply built sources, due to changes in the build system. My patches have attempted to remove all the complexity, and having ugly small source files is the price to pay. And you want to add back some complexity in the build system just to avoid those tiny files? I mean hypervisor and build system are complex software to write, do we really need to add complexity at every opportunity? -- Anthony PERARD