[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 01/12] util/log: convert debug_regions to GList
|
From: |
Sven Schnelle |
|
Subject: |
Re: [PATCH v3 01/12] util/log: convert debug_regions to GList |
|
Date: |
Mon, 04 Mar 2024 20:12:54 +0100 |
Alex Bennée <alex.bennee@linaro.org> writes:
>> So i wonder
>> whether we should convert all of those functions to GArray? (if
>> possible, i haven't checked)
>
> I think that would depend on access patterns and flexibility. For the
> dfilter there is no particular need for sorting and the principle
> operation is a sequence of lookups. For the other use cases keeping a
> sorted list and quick insertion might be more useful.
>
> While its tempting to go on a wider re-factoring I would caution against
> it so close to softfreeze.
>
>> What do you think?
>
> Lets stick to the dfilter case and worry about wider clean-ups later. As
> Richard points out it might be the interval tree makes more sense for
> some of these things.
I think i go with the GArray variant for now. I'd guess that -dfilter is
usually only used with one or a few arguments, so using a Interval Tree
is probably not neccessary.
[PATCH v3 06/12] util/range: split up range_list_from_string(), Sven Schnelle, 2024/03/01
[PATCH v3 05/12] util/range: use append_new_range() in range_list_from_string(), Sven Schnelle, 2024/03/01
[PATCH v3 02/12] util/log: make qemu_set_dfilter_ranges() take a GList, Sven Schnelle, 2024/03/01
[PATCH v3 03/12] util/range: move range_list_from_string() to range.c, Sven Schnelle, 2024/03/01
[PATCH v3 07/12] util/range: make range_list_from_string() accept a single number, Sven Schnelle, 2024/03/01
[PATCH v3 08/12] qemu/range: add range_list_contains() function, Sven Schnelle, 2024/03/01
[PATCH v3 04/12] util/range: add range_list_free(), Sven Schnelle, 2024/03/01
[PATCH v3 10/12] plugins: add range list API, Sven Schnelle, 2024/03/01
[PATCH v3 12/12] plugins/execlog: add data address match, Sven Schnelle, 2024/03/01