[RFC PATCH v2 16/19] dyndbg: ddebug_site_get/put api commentary

[Jim Cromie]

Paths forward: (not mutually exclusive)

A: !site -> fill from backing store

1st try at this is/was using zram.  At init, it copied each callsite
into a zs-allocation, and all site-> refs afterward went thru
_get/_put to zs-map on demand, and zs-unmap the site info.  This
worked until I tried to keep callsites mapped while they're enabled.

Another approach is to compress the new linker section, using some
algo thats good at indexed decompression.  I tried to test this a bit,
using objcopy, unsuccessfully:

   objcopy --dump-section __dyndbg_callsites=dd_callsites vmlinux.o

>From vmlinux.o it was mostly empty, vmlinux didnt have the section.

B: callsite as a set of property vectors, indexed by 'N'

We know dp is in a vector, either in the builtin __dyndbg_callsite
linker section, or the same from a modprobed one.  The builtin section
has all builtin module sub-sections catenated dogether.

At init, we iterate over the section, and "parse it" by creating a
ddebug_table for each module with prdebugs.  ddebug_table.num_debugs
remembers the size of each modules' vector of prdebugs.

We need a few things:

- _ddebug.index field, which knows offset to start of this sub-vector.
  this new field will be "free" because the struct has padding.
  it can be initialized during init, then RO.

- a back-pointer at the beginning of the sub-vector, to the
  ddebug_table "owning" (but not containing) this sub-vector of
  prdebugs.

If we had both, we could get from the ddebug element to its vector
root, back up to the owning ddebug_table, then down to the _callsite
vector, and index to the right element.  While slower than a pointer
deref, this is a cold path, and it allows elimination of the
per-callsite pointer member, thus greater density of the sections, and
still can support sparse site info.

That back-pointer feels tricky.  It needs to be 1st in the sub-vector

is to reserve the 0th slot

ing its spot at the
front of

each module's ddebug sub-vector.

getting space in the
section for it.  Initializing it is easy.

prdebugs are added to section when DECLARE_DYAMIC_DEBUG_METADATA is
compiled; its unclear whether they are intrinsically sorted during
compile, or whether thats a linker thing.

Ideally, a MODULE-mumble declaration can be coaxed into declaring a
module singleton in the section(s), either naturally at the top (or
bottom) or sorted into place.

If that doesn't work, a "preload if module is different" strategy
could maybe work, but I dont know how to do that in macros.

Signed-off-by: Jim Cromie <jim.cromie@xxxxxxxxx>
---
 lib/dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 25f49515c235..ec28c113a361 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -146,7 +146,7 @@ static void vpr_info_dq(const struct ddebug_query *query, const char *msg)
 
 static struct _ddebug_callsite *ddebug_site_get(struct _ddebug *dp)
 {
-	return dp->site;
+	return dp->site; /* passthru abstraction */
 }
 static inline void ddebug_site_put(struct _ddebug *dp)
 {
-- 
2.29.2