From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 26B843858D32 for ; Thu, 13 Apr 2023 21:17:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 26B843858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681420628; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HK/r4x/Jqe7HlNs4qX5yrYT6D6qdp4zB5vjmtiX/LIg=; b=b2QiORgvpus2Dxu7P8hdHWa04MJa5/RjdKfHR7+n6ILA8/e0s9nbhITRHXRemgE0uSwNCL RRcOqjBvXnokqPIuSpAg0Qn7ZP+nTCYPJW1WkefMVYu3IdhEQ/NMAP9xmSZ0gs92EeukU4 olgvK7Y7zRJvqO6rpLcWp5nSvkLGUK0= Received: from mail-yw1-f198.google.com (mail-yw1-f198.google.com [209.85.128.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-448-WpnTfwOcPyqyDC5M4JA_vg-1; Thu, 13 Apr 2023 17:17:07 -0400 X-MC-Unique: WpnTfwOcPyqyDC5M4JA_vg-1 Received: by mail-yw1-f198.google.com with SMTP id 00721157ae682-54f8d4f1ca1so70653757b3.20 for ; Thu, 13 Apr 2023 14:17:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681420627; x=1684012627; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HK/r4x/Jqe7HlNs4qX5yrYT6D6qdp4zB5vjmtiX/LIg=; b=JZw8OZuQsMO7ZldKP6nth3obZQxv2DxB5qV3kl3cEnp4DAvG/Y2XJ+9K+6NTRp0crH FDTYePNlG3VUvwpwrZS4uMUejm7ZnZyAIHmf/vWz+wDT4LTe3bzLAD59BI+ITFzOiJSj aGnVfpxqOJDWoKFOYq5VHXcczqHUXi5ju90qdGI6rCCSYtDRe6OlD8pFvjror3ls7rIJ IRVzNI/OXvARCTFnVbDrn/KKailnks5L758NITuY/A32mtkZBZ1jUon2RKRUqzU38RJr JsR5vviPt7TCkhWXKh8HlClfBqAQoHX4eDwbr5e6RVQJLywxbWUuz2Sq80y1nHCBmvwZ Ln0A== X-Gm-Message-State: AAQBX9cz7sjo5en8XRmxx83fmN62TxtwczUVP/JNKFZSAGcEGvO4owQo 0Cm1O9cYay9XqCldzgkSaf76w6eo2HRwhKtqOtKR/e3X5LcvgiWQ1xSFUKRkFnwA7RPvHuMQyGc 8YfaU5whakrUfxN9FaGFr X-Received: by 2002:a25:1d09:0:b0:b8c:ab:6484 with SMTP id d9-20020a251d09000000b00b8c00ab6484mr3024013ybd.10.1681420627292; Thu, 13 Apr 2023 14:17:07 -0700 (PDT) X-Google-Smtp-Source: AKy350YYLq8DwRR0t656kUgO+zEvD1km7vbWxWSNY9qcFFX+1EK9tBa7wnN742dDqq7fZCa29gbB1w== X-Received: by 2002:a25:1d09:0:b0:b8c:ab:6484 with SMTP id d9-20020a251d09000000b00b8c00ab6484mr3024002ybd.10.1681420627012; Thu, 13 Apr 2023 14:17:07 -0700 (PDT) Received: from [192.168.0.241] ([198.48.244.52]) by smtp.gmail.com with ESMTPSA id w10-20020a05690204ea00b00b7767ca747csm705570ybs.25.2023.04.13.14.17.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Apr 2023 14:17:06 -0700 (PDT) Message-ID: <23436bcf-a715-971b-db54-5d80634ca0ef@redhat.com> Date: Thu, 13 Apr 2023 17:17:05 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH v9 0/13] implement dlmem() function To: stsp , libc-alpha@sourceware.org, Jonathon Anderson 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> From: Carlos O'Donell Organization: Red Hat In-Reply-To: <09b644bc-3d6e-39cf-02c2-af5c5a72e248@yandex.ru> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: On 3/31/23 07:04, stsp wrote: > Hi Carlos, Jonathon. > > 29.03.2023 23:13, Carlos O'Donell пишет: >> The most important thing is the reasons for the change and that should come first. > > Done, please see the attachment. Your v10 cover letter is great and makes it completely clear what it is you want to implement. However, the API itself is just not acceptable to me as an abstraction that is generic enough to warrant inclusion in glibc. This is a design decision I'm making as a developer. In this thread you don't have consensus from Adhemerval, or myself as core glibc developers. 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: https://sourceware.org/glibc/wiki/Consensus You don't have consensus from Zach Weinberg (GNU Autoconf maintainer) who has also responded on the thread and is a GNU Toolchain contributor. Likewise you don't have conses from Rich Felker, who as an alternative libc developer would need to consider implementing something similar. I don't see any way to salvage this API as it is, and while it might serve your needs, the core C library is not designed to serve all needs, but to serve the most generic needs. The most generic needs can be seen by existing prior art like fdlopen or dlopen_with_offset(), and they have been implemented. >> This needs to explain the workload that requires the API. >> >> Why that workload is generic. >> >> Any core system library, like glibc, is not the place for *all* APIs, but the >> place for the most generic building blocks for ISO C, POSIX, BSD, GNU, and >> Linux APIs. > > I hope I've got that suggestion rightly. > Please see if my current description is > adequate. 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? What about replacing all the vDSO handling with the API? > And on the other front... > I studied and documented (in the attachment) > all the cases where my impl fails to arrange > an elf segments properly... I have to admit > such cases were possible. :( > I documented them and their mitigations in > the "Limitations" section. > Let me know if this is now adequate. These are well documented. You've really done a good job of calling them out. In summary: - This API as designed does not have consensus. Posting v10 does not fix the consensus problem. - I suggest dropping the feature for glibc. If there are other things you would like to work on in glibc, please reach out again. -- Cheers, Carlos.