Re: [PATCH v9 0/13] implement dlmem() function

[Carlos O'Donell <carlos@redhat.com>]

On 3/31/23 07:04, stsp wrote:
> Hi Carlos, Jonathon.
> 
> 29.03.2023 23:13, Carlos O'Donell пишет:
>> The most important thing is the reasons for the change and that should come first.
> 
> Done, please see the attachment.

Your v10 cover letter is great and makes it completely clear what it is
you want to implement.

However, the API itself is just not acceptable to me as an abstraction
that is generic enough to warrant inclusion in glibc. This is a design
decision I'm making as a developer.

In this thread you don't have consensus from Adhemerval, or myself as
core glibc developers. So this patch won't move forward towards inclusion
until you can get our consensus. This *blocks* this patch from ever being
included in glibc per consensus rules:
https://sourceware.org/glibc/wiki/Consensus

You don't have consensus from Zach Weinberg (GNU Autoconf maintainer) who
has also responded on the thread and is a GNU Toolchain contributor.

Likewise you don't have conses from Rich Felker, who as an alternative
libc developer would need to consider implementing something similar.

I don't see any way to salvage this API as it is, and while it might
serve your needs, the core C library is not designed to serve all needs,
but to serve the most generic needs.

The most generic needs can be seen by existing prior art like fdlopen
or dlopen_with_offset(), and they have been implemented.

>> This needs to explain the workload that requires the API.
>>
>> Why that workload is generic.
>>
>> Any core system library, like glibc, is not the place for *all* APIs, but the
>> place for the most generic building blocks for ISO C, POSIX, BSD, GNU, and
>> Linux APIs.
> 
> I hope I've got that suggestion rightly.
> Please see if my current description is
> adequate.

Not quite. A workload is application that would use the API in a specific way.

For example you don't mention which workloads would be improved by using these
APIs? Would an application use the APIs to accelerate or handling plugin loading?
What about loading DSOs from NVRAM? What about replacing all the vDSO handling
with the API?

> And on the other front...
> I studied and documented (in the attachment)
> all the cases where my impl fails to arrange
> an elf segments properly... I have to admit
> such cases were possible. :(
> I documented them and their mitigations in
> the "Limitations" section.
> Let me know if this is now adequate.

These are well documented. You've really done a good job of calling them out.

In summary:

- This API as designed does not have consensus. Posting v10 does not fix the
  consensus problem.

- I suggest dropping the feature for glibc. If there are other things you
  would like to work on in glibc, please reach out again.

-- 
Cheers,
Carlos.