From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) by sourceware.org (Postfix) with ESMTPS id DF9E538008BB for ; Wed, 11 May 2022 06:57:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DF9E538008BB Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=arndb.de Received: from mail-yw1-f181.google.com ([209.85.128.181]) by mrelayeu.kundenserver.de (mreue010 [213.165.67.97]) with ESMTPSA (Nemesis) id 1M2etD-1nmk523iEJ-004Esc for ; Wed, 11 May 2022 08:57:52 +0200 Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-2f863469afbso10485137b3.0 for ; Tue, 10 May 2022 23:57:51 -0700 (PDT) X-Gm-Message-State: AOAM531O6V1HzbouYYtXXz1nbKqcAeIHnmDRjcdBIGgsZ7jHPqwMX0CN PzMFam0C4I2FdWc3IECrCLbbhTnryCKNALN4j1o= X-Google-Smtp-Source: ABdhPJw/9K8q17LKkWu6ec0JmmbJg0Qaa3g62kg6/glZftWp8XRB8olrSLSI5KpA+XNu9Ijv4miFsaUc1efpO/hyYvM= X-Received: by 2002:a81:1697:0:b0:2fa:32f9:78c8 with SMTP id 145-20020a811697000000b002fa32f978c8mr23481217yww.135.1652252270435; Tue, 10 May 2022 23:57:50 -0700 (PDT) MIME-Version: 1.0 References: <20220509022611.1248063-1-caiyinyu@loongson.cn> <8735hhb2m9.fsf@oldenburg.str.redhat.com> In-Reply-To: <8735hhb2m9.fsf@oldenburg.str.redhat.com> From: Arnd Bergmann Date: Wed, 11 May 2022 08:57:33 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 00/13] GLIBC LoongArch PATCHES To: Florian Weimer Cc: caiyinyu , xuchenghua@loongson.cn, joseph_myers@mentor.com, GNU C Library Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:BbFRXeo72a6fkiyx/SGH/I0numyGesZIJh1x5vKMoGR6tXgn2pO wSUfv8kQQ/btgU0zLYxnsD0Vvhfvru7MhvniG8ZwZHTWVaPOr+9meRJc5yYhL5n1d3RgiTf /5g9JCPNlqR4n2Jqm2LNLncjZVCLkK7lj2IemGHQxYn1oxDQxsH+SFo+fEb6+lcOoBL0yM5 qfh9niJ2Qh+UNXoO0Eo0A== X-UI-Out-Filterresults: notjunk:1;V03:K0:dQ/f+mgGTXI=:gPmUpyCnGj110FT4AKQLHt pNJB1vsP4GV7snB11zk5dcxTNT4neYGW9v4uRKx2DzNSs+khqFAL6zIBQAJ1x+5xvcT/tso5M tyAB7ZbwoSBZqpnEAKKoAMaQHEPDfPu+3wSRTnbVD6UDlKuugF7tajb/2r5YADA853KI0WuTT 3gb+QhMCDxPHo+n+Og9zaabCUa99GwiH3DdVaz1DpaDOSSBX+JoCHGkq8w5MkcjtX22XGZcwu pgsV6AaAkkW2VOqwDuhB3Qv7GCIFlS/QRfN8NAp6KDf8itzswLESs9TeHWoJNDwyMA9B62KgG PALtcsGw/h75fsSo2Z79VSYGw1A7M/TQSIwLIW9W8MwgId9YzTgvmEq+Q2Bt+JIO9gQdQnz+x NdltoTLcUgLieRv//jh5HYnmIUjJsqwt9rfU43NjL4PfQoHnzOe2dUVb54cGiijtSF/yB0pSN Y1ld5GIKG/wVV8A4hK8wGsTbEGhDQlIxTv5D+UOaUQ6j1ByfYxvecpCSv8d9Q9/i9dUjkpdqw QQJgBmZTbMdBB1OiOqbMn1DM8hNvVr994Nc6vXXx0AQ37n+/HlgmlA58qZlvZXe0s2QaLMkcw Y5IO7B1k0jLWAmaJsACOateEqbVVCdWXlWbdH5uWdYSooQGU5SCLWZalPXoWLWe8tSEvTxuB5 3LuQOopPMMuB3ew3HMeAVXQpA3qz9ZmXgUXwXws6CNXdeAoLUURDkCRSuIa1nuisxP/E= X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2022 06:57:56 -0000 On Tue, May 10, 2022 at 9:37 PM Florian Weimer via Libc-alpha wrote: > > > GCC and Binutils Loongarch parts have been into GNU Open Source community. > > Loongarch kernal may be no problem on 5.19: > > It seems that the Linux 5.19 release date could be really close to the > glibc 2.36 release date, or even after it. I think we wouldn't want to > release with an ABI whose kernel interface is not in a mainline kernel > yet. > > We have the option to backdate ABIs, so we could release the port with a > GLIBC_2.36 ABI baseline in glibc 2.37. > > Or we could merge the port now, and back it out once more if Linux 5.19 > does not get released in time. > > Maybe it's sufficient if the Linux port makes it to mainline during the > 5.19 rc phase? > > Thoughts? >From the kernel side, there is only one open question on the ABI: either this will include both clone() and clone3(), or just clone3(). This is a surprisingly hard decision. Normally the policy in the kernel is that new architectures only get the latest syscall interface, dropping earlier syscalls in favor of backward-compatible new interfaces. For clone3(), this may not work out because - clone3 requires knowing the stack frame size for the child, but when emulating clone() in libc, that information may not be there. We need to work around this by allowing clone3 to be called without a size argument - some other architectures still don't implement clone3() since we are missing the assembly bits for it. So unlike the other recently added calls, there is no minimum kernel version that guarantees clone3 to be available. - the seccomp/bfp infrastructure in the kernel cannot currently introspect indirect syscall arguments. This has to be added at some point anyway, but until then the chrome sandbox disallows the clone3 syscall. The easy way out of course is to include both in the kernel, though this feels like taking a step backwards. If libc developers feel strongly either way, please also reply on the kernel thread so we can come to a consensus more quickly. There is still another open discussion that blocks merging the loongarch kernel port, but that is only for the bootloader and not visible to libc. We should merge it as soon as we have concluded both points, but it's unclear if that happens before the merge window. Arnd