Message ID | 1a6bac6a-7d83-f5b6-c5b9-8b3b39824d40@suse.com (mailing list archive) |
---|---|
Headers | show |
Series | xen: beginnings of moving library-like code into an archive | expand |
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,
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