From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward502a.mail.yandex.net (forward502a.mail.yandex.net [178.154.239.82]) by sourceware.org (Postfix) with ESMTPS id 91E5E3858D20 for ; Fri, 14 Apr 2023 07:07:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 91E5E3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=yandex.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yandex.ru Received: from mail-nwsmtp-smtp-production-main-64.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-64.vla.yp-c.yandex.net [IPv6:2a02:6b8:c0f:170e:0:640:d60c:0]) by forward502a.mail.yandex.net (Yandex) with ESMTP id 967695EB81; Fri, 14 Apr 2023 10:07:13 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-64.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id A7SsxDCDY0U0-JF1TNUxi; Fri, 14 Apr 2023 10:07:12 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1681456033; bh=OCGTIbB/NQhGflEl5uuhmy1Zdelk0xyhBYgFeMaspTI=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=pWcTC8YAHHgo//Y/+j3oNOpDDAuA7FVD4Kgn70tuD7mznaBUZNM5SsFr9V80ZCQuq guuQt9yYc/XlAC5l1Tcx3Fdp+VMSy8vH8/0P45D81RUvNy50ZzqPbP1l4xhG//qMVT axunm9ntv3DOR/V3kO2exjSiyV2mYVf18axnKydQ= Authentication-Results: mail-nwsmtp-smtp-production-main-64.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Date: Fri, 14 Apr 2023 12:07:10 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v9 0/13] implement dlmem() function Content-Language: en-US To: Adhemerval Zanella Netto , Szabolcs Nagy , Rich Felker Cc: libc-alpha@sourceware.org, janderson@rice.edu, Carlos O'Donell , Zack Weinberg References: <298b04a6-3055-b89b-59c1-4cfbe955848e@yandex.ru> <81749d04-8cdb-de0b-b88e-24347ed535ba@yandex.ru> <729710b5-6dae-d5f2-99ee-6923be5e627d@yandex.ru> <20230412182043.GI3298@brightrain.aerifal.cx> <08d9ca95-112c-d85e-8e82-7a595ef4d051@yandex.ru> <78b5b5dc-5657-4bf8-24c6-6c00afb1cc40@yandex.ru> <83ee7b42-7a50-e8d1-e9ca-58ec2a12a995@linaro.org> <59862084-0fe3-7642-d3b3-01bb87eef7db@yandex.ru> <52d0b5e8-2c81-66e6-60dc-771d01b26fd6@linaro.org> From: stsp In-Reply-To: <52d0b5e8-2c81-66e6-60dc-771d01b26fd6@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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.