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

[stsp]

Hi Carlos,

14.04.2023 02:17, Carlos O'Donell пишет:
> In this thread you don't have consensus from Adhemerval, or myself as
> core glibc developers.

Have you forgot to reply to this e-mail:

https://sourceware.org/pipermail/libc-alpha/2023-March/146742.html

I sent you a proof, I asked multiple times
(including privately) was a proof adequate.
But you haven't replied, and haven't dropped
that malicious "elf parsing" argument.
Can you do that now?
Was my proof sufficient, or should I code
up another one?


>   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:

You perfectly know what _actually_ blocks it.
And its a small and simple fact: you have never
replied to my proof, that I sent to you by your
own request. You haven't put down the malicious
"elf parsing" argument, and haven't said the proof
was insufficient (or sufficient).

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

I wasn't CCed with this, and doing a "thread view"
via web interface doesn't allow me to find his e-mail.
Could you please provide an URL?

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

The API is in draft.
Draft can't be in consensus with everyone,
especially until you tell me whether the proof
was sufficient or not.

> I don't see any way to salvage this API as it is,

As it is it shouldn't be included.
Its a draft that should be _discussed_.
Its discussed only by Szabolcs, and very
unfortunately there are also the aforementioned
affairs going on about your "elf parsing" thing.


> 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?

OK I'll try to summarize those in the next draft.
Basically the estimation is that this API is very
much comparable with the existing dlopen() in
speed, as it doesn't use slow functions like read()
or memcpy() (well, memcpy() behavior exists
but its not a default one). Whether it increases
or decreases the syscall amount per DSO is
difficult to say (will need to measure), but even
if it does, the overhead would be a couple of
syscalls per DSO.


>   What about replacing all the vDSO handling
> with the API?

My estimation is that you will measure no changes.
Of course the final draft will need the benchmark
numbers, but its too early to add just yet.


> - I suggest dropping the feature for glibc. If there are other things you
>    would like to work on in glibc, please reach out again.
Why not to reply to the aforementioned e-mail
to at least make such a statement fair?