lkl: hijack: move dbg_handler out of liblkl

[ddiss]

dbg_handler exposes a very useful debug shell, but it's currently only used (within tools/lkl at least) by hijack.
Move the functionality into liblkl-hijack, to slightly trim down the liblkl core library.
This may break external lkl_register_dbg_handler() callers.

[ddiss]

flagging as draft as it's an API breakage... if we want to retain a signal-based debug hook then maybe it'd make sense to add a callback parameter instead, e.g. lkl_register_dbg_handler_fn(<callback function>, <fn_param>).

[tavip]

LGTM, I am not too concerned with this API change. @thehajime any thoughts?

[ddiss]

v2:

• fix zpoline linker error
• move dbg.c source in with dbg_handler.c
  • the unmodified source causes checkpatch errors

[thehajime]

@ddiss @tavip
thanks for the patch. overall looks good to me.

I just wish to know the motivation part of this patch; do we have an impact on trimming down the size of core library ?

Move the functionality into liblkl-hijack, to slightly trim down the liblkl core library.

I was wondering what motivates you to prepare this patch, as this introduces the API breakage (as you mentioned), we may not know the user of our library (liblkl.so) who uses this feature.

[ddiss]

thanks for the patch. overall looks good to me.

Thanks for the review.

I just wish to know the motivation part of this patch; do we have an impact on trimming down the size of core library ?

Move the functionality into liblkl-hijack, to slightly trim down the liblkl core library.

I was wondering what motivates you to prepare this patch, as this introduces the API breakage (as you mentioned), we may not know the user of our library (liblkl.so) who uses this feature.

I don't have a strong motivation for this one. Aside from the small size reduction, I was mostly considering ongoing maintenance and mainlining, where a simpler API should help.

[thehajime]

I don't have a strong motivation for this one. Aside from the small size reduction, I was mostly considering ongoing maintenance and mainlining, where a simpler API should help.

thanks for the description. I'm fine to merge this. We can revert (or refactor) it if somebody tells it.