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

[stsp <stsp2@yandex.ru>]

Hi Adhemerval,

14.04.2023 01:02, Adhemerval Zanella Netto пишет:
> Because it is the same remark bought *multiple* times in this thread [1]
> that you keep saying it is not important on the discussion:
>
> "It would be possible to require the caller to arrange all of
> these things, but that's basically offloading A LOT of the ELF
> loading process onto the calling program and I don't think that
> makes for a reasonable public interface for glibc to provide."
OK, I got off of an another shock from this, and am
absolutely calm again, just having a headache...
So lets get to the facts.

1.  There is now a written spec that explicitly
      says what is required. It says exactly how
      the solib should be put to the memory buffer,
      what types of mapping are supported, what
      types unsupported, how to dlmem() from
      aligned buffer, from unaligned buffer, from
      file-mapped buffer, and so on. So the whole
      "A LOT of the ELF loading process" is now
      fully specified and detailed.

2. The quote you did above, doesn't reveal the
     whole story. This URL does:

https://inbox.sourceware.org/libc-alpha/b6a96687-9a4b-414f-849a-45a305898274@redhat.com/

In this e-mail Carlos does claims that directly
contradict my spec. And based on them, not
based on my spec (!!!) he concludes that my
API is unacceptable. How can the one conclude
some API is unacceptable, writing his own (wrong)
spec of it? That's very strange, isn't it?

If my spec clearly say you only need to mmap()
the solib, and some alternative spec says you
need to also arrange elf segments by hands
before calling dlmem(), then how can this even
be the truth if we discuss _my_ spec? Maybe
Carlos reverse-engineered my implementation
of a spec, and found that it doesn't conform to
my own spec? And wrote his own one that matches
my implementation? I very much doubt so, but
even if this is true, then why not to point me to
such a bug in an implementation, and ask to
make it so that it matches _my_ spec? Why not
to ask me to make the loader itself to arrange
an elf segments, if it is not the case right now?
(but of course it is, that was proved many times)

So overall, I discuss my spec, Carlos discusses
his own. Why is it productive?

If it is widely believed my impl doesn't match
my own spec, then can we for a moment forget
about an impl, and discuss only my spec? It
clearly says that mapping the segment is a
loader's responsibility. I even explicitly wrote
that the mmapped image should not be modified,
or dlmem() won't work. Do we discuss _that_
spec, or some other spec of Carlos? That's what
I'd like to hear an answer to.

> And every time someone brought it [2], you just reply that this since it
> does not fit in your usercase this is not an acceptable solution.
This is yet another misunderstanding.
I say that when people offer me memfd+dlopen
replacement. That doesn't work for me, but it
has zero relevance to the discussed "Carlos's
spec of my API".

Now. I apologize if my yesterday's mails were
a bit rough. I hope we can all be technical and
I wish we all can always be calm. But when my
spec is replaced and another one is being used
to "justify" my work, I am really feeling quite bad.

Lets get technical, lets stick to facts and to my spec,
please. :)
If my spec says no elf parsing or segment
arranging is needed, then lets _believe_ that
my implementation matches it, please.