[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH v7 05/51] x86/mm: avoid building multiple .o from a single .c file

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • Date: Thu, 9 Sep 2021 11:03:04 +0100
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "Tim Deegan" <tim@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 09 Sep 2021 10:03:17 +0000
  • Ironport-hdrordr: A9a23:dlFoSaHOfsfhSQjwpLqE6seALOsnbusQ8zAXP0AYc31om+ij5q eTdZUgpHvJYVkqNE3I9eruBEDEewK7yXcX2/h1AV7BZniEhILAFugLhuGO/9SjIVydygc079 YYT0EUMr3N5DZB4/rH3A==
  • Ironport-sdr: Beew7uxmj13Bf6E7BNydK8vV6TYcJqe4lFR7RgGL6M1GtVcvhQO1/klaiR+xBrIiW/OaB699zQ 4Tpbx1mFQx4axiKrz4ijccBj3bCBmH2UWj5+5ErYZbj4J+GC2OmQZMsCccvC+G+PF6xdrkOpw7 7IVpTFS8J3deaF9bfg7vA1a2HeOISzqTuBfn7uBeaesg2UbUkE0rSWm/qMzeECPjPBmhY7x0qE tFWw3outJTEQzSF5GBKhGC0UJb8HmPWG0f0moEFqEQpxcNVNl7/wivYUHpIpjcY5p30qxMrFYc mFUw8KV5KShNbMUSvXGgjRZa
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.