Re: [PATCH v3 0/8] xen: beginnings of moving library-like code into an archive

[Bertrand Marquis <Bertrand.Marquis@arm.com>]

Hi Jan,

I will review this today, sorry for the delay.

Regards
Bertrand

> On 23 Nov 2020, at 15:16, Jan Beulich <jbeulich@suse.com> wrote:
> 
> In a few cases we link in library-like functions when they're not
> actually needed. While we could use Kconfig options for each one
> of them, I think the better approach for such generic code is to
> build it always (thus making sure a build issue can't be introduced
> for these in any however exotic configuration) and then put it into
> an archive, for the linker to pick up as needed. The series here
> presents a first few tiny steps towards such a goal.
> 
> Note that we can't use thin archives yet, due to our tool chain
> (binutils) baseline being too low.
> 
> Further almost immediate steps I'd like to take if the approach
> meets no opposition are
> - split and move the rest of common/lib.c,
> - split and move common/string.c, dropping the need for all the
>  __HAVE_ARCH_* (implying possible per-arch archives then need to
>  be specified ahead of lib/lib.a on the linker command lines),
> - move common/libelf/ and common/libfdt/.
> 
> v3 has a new 1st patch and some review feedback addressed. See
> individual patches.
> 
> 1: xen: fix build when $(obj-y) consists of just blanks
> 2: lib: collect library files in an archive
> 3: lib: move list sorting code
> 4: lib: move parse_size_and_unit()
> 5: lib: move init_constructors()
> 6: lib: move rbtree code
> 7: lib: move bsearch code
> 8: lib: move sort code
> 
> Jan
>