On Tue, Apr 22, 2025, at 9:45 AM, Aaron Merey wrote:
> Hi Serhei,
>
> On Tue, Apr 22, 2025 at 9:27 AM Serhei Makarov <ser...@serhei.io> wrote:
>>
>> On Mon, Apr 21, 2025, at 12:29 AM, Aaron Merey wrote:.
>> >
>> > I know we're close to the next release and I do want this work to be
>> > included. My proposal is to move the current API out of libdwfl and
>> > into a new library, as-is but clearly marked as experimental and
>> > subject to possible API/ABI breakage. This fits with the
>> > "experimental" label that eu-stacktrace still carries. The new
>> > functionality introduced in this series makes it into the release and
>> > we retain flexibility to iterate on the design without affecting
>> > libdwfl itself.
>> Do you want this to be done for the processtracker interface as well, or
>> only the ~two functions that mention perf fields in the API?
>>
>> I can do either option. Can you let me know what name you want for the
>> library? eg libdwfl_perf libstacktrace libdwfl_stacktrace …
>
> Let's move the process_tracker interface as well for additional
> flexibility to modify if needed. As for a name, I like
> libdwfl_stacktrace. It clearly communicates the purpose of the library
> and it's open to the possibility of supporting non-perf samples. It
> also avoids namespace collision (the name libstacktrace is already
> used by other projects).
Agreed re: stability impacts.
Is keeping a dwfl_ prefix for the apis acceptable? Inventing a new one might
lead to silly and verbose function names unless we come up with an abbreviation
like dwflst_
One question this raises re: the Dwfl_Process_Tracker structure and where its
implementation should be located. In the patches, the Dwfl struct
implementation includes a pointer to a Dwfl_Process_Tracker. I’m not sure if
elfutils currently has a ‘lower’ level library refer to symbols from a library
that uses it. Would the circular dependency cause any problems?
--
All the best,
Serhei
http://serhei.io
