From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward501a.mail.yandex.net (forward501a.mail.yandex.net [IPv6:2a02:6b8:c0e:500:1:45:d181:d501]) by sourceware.org (Postfix) with ESMTPS id E86DB3858D20 for ; Thu, 13 Apr 2023 21:58:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E86DB3858D20 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-49.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-49.vla.yp-c.yandex.net [IPv6:2a02:6b8:c18:3487:0:640:5432:0]) by forward501a.mail.yandex.net (Yandex) with ESMTP id 6D46D5EB84; Fri, 14 Apr 2023 00:58:30 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-49.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id SwfsqB8DSSw0-1LZhlTrc; Fri, 14 Apr 2023 00:58:30 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1681423110; bh=a9NJch052lMSv3ls2/WT9VeqpRKSSDXnqPEvZWZKKhs=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=Ko6fZNaMFPz5AvFJUbaqteE8GMKhFftf2lJP3UpsvPZ+dTKWYvLgbR13IdI1UODkM PjyASJum+UwgxCYrl1njs//Wx5dpLS4z7iHVsQwkOp+kRTyISu/P3BnChXSy2oig63 aswbAma++3a19c+/PtXuLbzJx2Aq3TJHVYVq5Lec= Authentication-Results: mail-nwsmtp-smtp-production-main-49.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Date: Fri, 14 Apr 2023 02:58:28 +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: Carlos O'Donell , libc-alpha@sourceware.org, Jonathon Anderson , Adhemerval Zanella Netto References: <20230318165110.3672749-1-stsp2@yandex.ru> <481ef2c5-a59f-dea4-7f5f-2fcd229a4c25@redhat.com> <7fab954f-4a3d-0df0-8211-a9697f3966c1@yandex.ru> <81d75bd3-147e-f85a-9955-0c7f0f2dfbeb@redhat.com> <09b644bc-3d6e-39cf-02c2-af5c5a72e248@yandex.ru> <23436bcf-a715-971b-db54-5d80634ca0ef@redhat.com> From: stsp In-Reply-To: <23436bcf-a715-971b-db54-5d80634ca0ef@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.7 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 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 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?