From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward500c.mail.yandex.net (forward500c.mail.yandex.net [IPv6:2a02:6b8:c03:500:1:45:d181:d500]) by sourceware.org (Postfix) with ESMTPS id 4E0E53858D32 for ; Fri, 14 Apr 2023 11:30:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4E0E53858D32 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-36.iva.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-36.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:a812:0:640:152a:0]) by forward500c.mail.yandex.net (Yandex) with ESMTP id 013045F203; Fri, 14 Apr 2023 14:30:47 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-36.iva.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id iUWDZMFDYqM0-b1Eu329n; Fri, 14 Apr 2023 14:30:46 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1681471846; bh=mx+8uHvufjsbbaXaKvzBA3huHgxKyKyvpu+iNYldW7s=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=BZcx01L9FQm3fHQPm+Si/nwgKOJLWUc+iMqvdFzvCiYi4LLpRwQoRt7CKTZ2IhdaW wThIwaix+qqrj1TQreUWAC0wNhp6lsAUKjFbYPAtFt6mvkQLm4NplmFBISkrOGQkpd hQClckJAIkOsvoFncH+1nUMzmPYl7dRBxEfwjTQk= Authentication-Results: mail-nwsmtp-smtp-production-main-36.iva.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Date: Fri, 14 Apr 2023 16:30:44 +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.5 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,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: 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." Now let me quote the relevant part of _my_ spec: - If you use a private file-backed mapping, then it shouldn't be   modified by hands before passing to dlmem(). I.e. you can't apply   mprotect() to it to change protection bits, and you can't apply   memmove() to it to move the solib to the beginning of the buffer,   and so on. dlmem() can only work with "virgin" private file-backed   mappings. That's what _my_ spec says. Why can't we just settle on a fact that anything that contradicts my spec, be it taken from some 10-years-old thread or from elsewhere, cannot be used as an argument when judging my API? Why can't we settle on a fact that even the attempts to do so are unacceptable, especially the repetitive attempts? We discuss my spec, so replacing its parts during the discussion, is counter-productive. > Because every time someone bring the corner cases you just dismiss saying > that either the person does not understand you [1] and it is up to review > prove you are wrong; Because the reviewer must not operate on some other spec when judging my spec. If the reviewer thinks his spec describes my proposed implementation better than my own spec, then he should better actually try to prove that. But at the end I presented my own proof that my impl is conforming: https://sourceware.org/pipermail/libc-alpha/2023-March/146742.html And now the question is simple: what else should be done on my side to have that case finally resolved? Code up some other proof? Write more clearly in a spec that no elf parsing is needed? Its a simple question, just what should I do? You tell - I do.