From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id 65FFE3858C5E for ; Wed, 8 Feb 2023 11:27:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 65FFE3858C5E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu Received: by mail-wr1-x433.google.com with SMTP id bu23so552174wrb.8 for ; Wed, 08 Feb 2023 03:27:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=z+2rOHz9tSAGBy9Y+pgokhiKeNqaDJcM+EPHpowywHY=; b=G1dVtnNBAgQlZZmVp+twnwj1JV8nwbDZ+9l1cHxdxuPFHlb5MwR06nCVnLJiys40b9 3y5wbx2oPr6ANr6hugoA5nG/mS4qZkX66bEl9Cqmz/a1/9EMe+O1OiIO0rtQ/MMyxaUb DV3au48AdSBeZwIwHuGEm1GIGFqPn6lPCNshxWU4P78opqzgSU+yQ8P2RbBYBy0uX5CX QAuTlXGlx1naujHE5Lb8OY8w3pH3uxlQ4+nAxLPfqc+KklorrGch4W6jXklkMv7vCoBZ CUxtjsoHz1YZMo010tlzSMDdVwFjDS1Ms0oeN7PFCnkMcumNvqKB/Mr+8+Z8UtTVSqAv IkDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=z+2rOHz9tSAGBy9Y+pgokhiKeNqaDJcM+EPHpowywHY=; b=DO84jaMEehDvs9H3RmGdIHiBewZbWkhfV175//1pTV/U55o6u2NsIgAfDEDii2Xjiz ZSPxyd9SDRrbJNmNbocR7aEXIPSmX13JP5qzEOSVKV+BIWrnup5IWjo4Qbse85yo4vka FZsd+3hgAQ2SCOnKaT4dicIKO4qrifHneyIhnfAaJ2bt7kSGR1Lsw3zH8EXBeb2n7bHz ZYyYa2PI7e//E3eX9rY11vFg08cwa0UQ/oSA5lcMnH/V3JNMUaH9TbSi2iwQIVughsBj qKdFGp6dRuxDcotphE4x2+wp4CkTzRIUQ2jRdCWM+MMf7Z1qcZs5Z1jJq0tctrQEr89J 0UPg== X-Gm-Message-State: AO0yUKVkauyXUdNz/1kK2/Lu5PA3C/AXVMyHI6dNerf3zDU9YxmZ9xHM ukmr1BAe+VhDNIsPn65jjBhkid7Wjahfy+9ilbPijw== X-Google-Smtp-Source: AK7set93XSvjyMd84qtjuwnwIDxPeSeoCtJkg3f2stvmL27k+ORd9mC+lgaRnv0NAcxt4IyV/mgxqnZeQi/Dik9iOjI= X-Received: by 2002:adf:e4c9:0:b0:2bd:f375:a55b with SMTP id v9-20020adfe4c9000000b002bdf375a55bmr206078wrm.328.1675855620094; Wed, 08 Feb 2023 03:27:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Christoph_M=C3=BCllner?= Date: Wed, 8 Feb 2023 12:26:46 +0100 Message-ID: Subject: Re: [RFC PATCH 00/19] riscv: ifunc support with optimized mem*/str*/cpu_relax routines To: DJ Delorie Cc: Philipp Tomsich , adhemerval.zanella@linaro.org, libc-alpha@sourceware.org, palmer@dabbelt.com, darius@bluespec.com, andrew@sifive.com, vineetg@rivosinc.com, kito.cheng@sifive.com, jeffreyalaw@gmail.com, heiko.stuebner@vrull.eu Content-Type: multipart/alternative; boundary="000000000000ee4d0205f42e8ac3" X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000ee4d0205f42e8ac3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 7, 2023 at 10:14 PM DJ Delorie wrote: > > Philipp Tomsich writes: > > So this patch has always been a stand-in until option #2 is ready. > > I am strongly opinionated towards a mechanism that uses existing > > mechanisms in the ELF auxiliary vector to pass information =E2=80=94 an= d tries > > to avoid the introduction of a new arch-specific syscall. if possible. > > If the patch were converted to use tunables, it could be more than a > standin. It's the environment variable itself I'm opposed to. > Thanks DJ and Adhemerval for your valuable inputs! As said in the cover letter, the environment variable approach was not meant to be merged but represents a starting point for discussions. It is not what we want but serves as a dirty placeholder, that allows development of optimized routines. The IFUNC support and the kernel-userspace API was discussed multiple times in the past (e.g. on LPC2021 and LPC2022). There are different opinions on the approaches so the whole process is regularly getting stuck. The topic, where most (if not all) in the RISC-V community agree on, is that we don't want a compile-time-only approach. Patches that rely on a compile-time-only approach are most likely written such, because of the absence of ifunc support. Meanwhile, we have heard from multiple vendors to work on their own solutions downstream, which results in a duplication of work and not necessarily in a common solution upstream. This patchset was sent out to move the discussion from the idea level to actual code, which can be reviewed, criticized, tested, improved, and reused (get a common ground for RISC-V vendors). Both of your comments show how we can move this patchset forward: - eliminate the first patch See also: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30095 - work on the kernel-userspace interface to query capabilities - use tunables instead of env variable - look how we can reuse more of the generic implementation to minimize ASM code with little or no benefits I fully agree with all the mentioned points. Thanks, Christoph --000000000000ee4d0205f42e8ac3--