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

On Mon, Nov 23, 2020 at 04:16:02PM +0100, Jan Beulich wrote:
[...]
> 
> 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

Acked-by: Wei Liu <wl@xen.org>

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
> 

On 09.12.2020 12:33, Bertrand Marquis wrote:
> I will review this today, sorry for the delay.

Thanks for the reviews, and no problem at all. Since iirc it was
you who asked on the last community call, I wanted to point out
that despite your reviews and despite Wei's acks the series
still won't be able to go in, because patches 2 and 3 are still
lacking Arm maintainer acks.

Jan

On 09/12/2020 14:47, Jan Beulich wrote:
> On 09.12.2020 12:33, Bertrand Marquis wrote:
>> I will review this today, sorry for the delay.
> 
> Thanks for the reviews, and no problem at all. Since iirc it was
> you who asked on the last community call, I wanted to point out
> that despite your reviews and despite Wei's acks the series
> still won't be able to go in, because patches 2 and 3 are still
> lacking Arm maintainer acks.

I am waiting on Anthony's input before giving my ack on patch 2. I am 
not sure whether he is already on holidays.

Cheers,

-- 
Julien Grall

On 09.12.2020 15:51, Julien Grall wrote:
> On 09/12/2020 14:47, Jan Beulich wrote:
>> On 09.12.2020 12:33, Bertrand Marquis wrote:
>>> I will review this today, sorry for the delay.
>>
>> Thanks for the reviews, and no problem at all. Since iirc it was
>> you who asked on the last community call, I wanted to point out
>> that despite your reviews and despite Wei's acks the series
>> still won't be able to go in, because patches 2 and 3 are still
>> lacking Arm maintainer acks.
> 
> I am waiting on Anthony's input before giving my ack on patch 2.

Well, okay. I'll continue to wait then. What about patch 3 though?

Jan