Re: Re: [musl] Port the new architecture loongarch64 to musl

[翟小娟 <zhaixiaojuan@loongson.cn>]

Yes, we are still using faccessat on the kernel. After the kernel is updated later, we will eliminate these system calls in the musl source code.
We have already adapted the tool chain, libc, kernel and qemu source code. To ensure quality, we are currently undergoing further testing and verification. We plan to start submitting to the community next month. If necessary, we can provide a physical machine or qemu.


> -----原始邮件-----
&gt; 发件人: "Arnd Bergmann" <arnd@kernel.org>
&gt; 发送时间: 2021-05-08 05:58:15 (星期六)
&gt; 收件人: musl@lists.openwall.com
&gt; 抄送: "陈国祺" <chenguoqi@loongson.cn>
&gt; 主题: Re: [musl] Port the new architecture loongarch64 to musl
&gt; 
&gt; On Fri, May 7, 2021 at 11:01 AM 翟小娟 <zhaixiaojuan@loongson.cn> wrote:
&gt; &gt;
&gt; &gt; Hi,
&gt; &gt; I ported a new architecture loongarch64 on the latest branch of musl master. It has been successfully compiled and run the official test libraries libc-testsuit and libc-test of musl.
&gt; &gt; The source code of the prot has been published in https://github.com/loongson-community/musl.  Or check the attachment 0001-port-to-loongarch64.patch, it is the transplanted patch file.
&gt; 
&gt; It's nice to see upstreaming work for loongarch64.
&gt; 
&gt; I'm mainly interested in the kernel side of this, as I review any new
&gt; ports of Linux
&gt; to new architectures.
&gt; 
&gt; Looking at the system call interfaces, I see that you used the generic ABI,
&gt; so there is a good chance that this will not require incompatible changes,
&gt; but a proper review of the kernel port will be necessary to be sure.
&gt; 
&gt; I did notice that the system call list is a bit outdated and does not
&gt; reflect the
&gt; latest kernel, but that should be easy to change. There are a few system calls
&gt; that are technically obsoleted by newer variants now, and we may decide to
&gt; drop them for new architectures in favor of the newer variants, e.g. openat,
&gt; faccessat, and io_getevents.
&gt; 
&gt; The order I would generally recommend for upstreaming is:
&gt; 
&gt; 1. toolchain (either gcc/binutils or clang)
&gt; 2. kernel
&gt; 3. libc
&gt; 4. everything else
&gt; 
&gt; If you do the order differently, there is a risk that ABI changes in one of the
&gt; lower levels require changing the upper levels later on.
&gt; 
&gt;         Arnd
</zhaixiaojuan@loongson.cn></chenguoqi@loongson.cn></arnd@kernel.org>