mailing list of musl libc
 help / color / mirror / Atom feed
* Re: [musl] Port the new architecture loongarch64 to musl
       [not found] <5f6d09a5.c3a.179460eee20.Coremail.zhaixiaojuan@loongson.cn>
@ 2021-05-07 21:58 ` Arnd Bergmann
  2021-05-08  5:16   ` 翟小娟
       [not found] ` <CAE2XoE_9sQrizuiy0afA1dQdPxgOkPda_39oB9DOJN1c2FB0Cw@mail.gmail.com>
       [not found] ` <32e9f7ee-bd3c-762a-a771-2da41a8c1bb0@dereferenced.org>
  2 siblings, 1 reply; 10+ messages in thread
From: Arnd Bergmann @ 2021-05-07 21:58 UTC (permalink / raw)
  To: musl; +Cc: 陈国祺

On Fri, May 7, 2021 at 11:01 AM 翟小娟 <zhaixiaojuan@loongson.cn> wrote:
>
> Hi,
> 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.
> 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.

It's nice to see upstreaming work for loongarch64.

I'm mainly interested in the kernel side of this, as I review any new
ports of Linux
to new architectures.

Looking at the system call interfaces, I see that you used the generic ABI,
so there is a good chance that this will not require incompatible changes,
but a proper review of the kernel port will be necessary to be sure.

I did notice that the system call list is a bit outdated and does not
reflect the
latest kernel, but that should be easy to change. There are a few system calls
that are technically obsoleted by newer variants now, and we may decide to
drop them for new architectures in favor of the newer variants, e.g. openat,
faccessat, and io_getevents.

The order I would generally recommend for upstreaming is:

1. toolchain (either gcc/binutils or clang)
2. kernel
3. libc
4. everything else

If you do the order differently, there is a risk that ABI changes in one of the
lower levels require changing the upper levels later on.

        Arnd

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Re: [musl] Port the new architecture loongarch64 to musl
  2021-05-07 21:58 ` [musl] Port the new architecture loongarch64 to musl Arnd Bergmann
@ 2021-05-08  5:16   ` 翟小娟
  2021-05-09  7:56     ` Arnd Bergmann
  0 siblings, 1 reply; 10+ messages in thread
From: 翟小娟 @ 2021-05-08  5:16 UTC (permalink / raw)
  To: musl; +Cc: 陈国祺

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; -----原始邮件-----
&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>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Re: [musl] Port the new architecture loongarch64 to musl
       [not found] ` <CAE2XoE_9sQrizuiy0afA1dQdPxgOkPda_39oB9DOJN1c2FB0Cw@mail.gmail.com>
@ 2021-05-08  5:18   ` 翟小娟
  0 siblings, 0 replies; 10+ messages in thread
From: 翟小娟 @ 2021-05-08  5:18 UTC (permalink / raw)
  To: musl; +Cc: 陈国祺

Yes, we have ported loongarch64 qemu and plan to submit it to the community in June


-----原始邮件-----
发件人:"罗勇刚(Yonggang Luo)" <luoyonggang@gmail.com>
发送时间:2021-05-08 00:29:40 (星期六)
收件人: Musl <musl@lists.openwall.com>
抄送: "陈国祺" <chenguoqi@loongson.cn>
主题: Re: [musl] Port the new architecture loongarch64 to musl

Same question, does qemu have already support for  loongarch64, that's means a lot for auto testing
As the real hardware will be not broadly  available in the next few years.  
  
 

On Fri, May 7, 2021 at 5:01 PM 翟小娟 <zhaixiaojuan@loongson.cn> wrote:
Hi,
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.
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.

Introduction to loongarch architecture:
The Loongarch architecture is a simplified instruction computer style instruction system architecture. The instruction length is fixed and the encoding format is regular. Most instructions have only two source operands and one destination operand. The load/store architecture is adopted, that is, only load/store memory access instructions can access the memory, and the operation objects of other instructions are all It is the immediate value in the register or instruction code in the processor core.
The Loongson architecture is divided into two versions, 32bit and 64bit, called LA32 and LA64 respectively. LA64 architecture application level is downward binary compatible with LA32 architecture.



-- 
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo


</zhaixiaojuan@loongson.cn></chenguoqi@loongson.cn></musl@lists.openwall.com></luoyonggang@gmail.com>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Re: [musl] Port the new architecture loongarch64 to musl
       [not found] ` <32e9f7ee-bd3c-762a-a771-2da41a8c1bb0@dereferenced.org>
@ 2021-05-08  5:23   ` 翟小娟
  2021-05-08  7:49     ` Ariadne Conill
  0 siblings, 1 reply; 10+ messages in thread
From: 翟小娟 @ 2021-05-08  5:23 UTC (permalink / raw)
  To: musl; +Cc: 陈国祺

Yes, we refer to mips. 
qemu plans to submit to the community in the near future. For testing and verification, we can provide physical machines or qemu.


&gt; -----原始邮件-----
&gt; 发件人: "Ariadne Conill" <ariadne@dereferenced.org>
&gt; 发送时间: 2021-05-07 23:57:22 (星期五)
&gt; 收件人: musl@lists.openwall.com
&gt; 抄送: "陈国祺" <chenguoqi@loongson.cn>
&gt; 主题: Re: [musl] Port the new architecture loongarch64 to musl
&gt; 
&gt; Hello,
&gt; 
&gt; On Fri, 7 May 2021, 翟小娟 wrote:
&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;
&gt; &gt; Introduction to loongarch architecture:
&gt; &gt; The Loongarch architecture is a simplified instruction computer style instruction system architecture. The instruction length is fixed and the encoding format is regular. Most instructions have only two source operands and one destination operand. The load/store architecture is adopted, that is, only load/store memory access instructions can access the memory, and the operation objects of other instructions are all It is the immediate value in the register or instruction code in the processor core.
&gt; &gt; The Loongson architecture is divided into two versions, 32bit and 64bit, called LA32 and LA64 respectively. LA64 architecture application level is downward binary compatible with LA32 architecture.
&gt; 
&gt; To confirm, Loongarch is basically a fork of MIPS, right?  At least 
&gt; everything seems quite similar in that regard from the patch.  Do you have 
&gt; a simulator available for testing with?
&gt; 
&gt; Ariadne
</chenguoqi@loongson.cn></ariadne@dereferenced.org>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Re: [musl] Port the new architecture loongarch64 to musl
  2021-05-08  5:23   ` 翟小娟
@ 2021-05-08  7:49     ` Ariadne Conill
  2021-05-12  9:30       ` 翟小娟
  0 siblings, 1 reply; 10+ messages in thread
From: Ariadne Conill @ 2021-05-08  7:49 UTC (permalink / raw)
  To: musl; +Cc: 陈国祺

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

Hello,

On Sat, 8 May 2021, 翟小娟 wrote:

> Yes, we refer to mips. 
> qemu plans to submit to the community in the near future. For testing and verification, we can provide physical machines or qemu.

The qemu patch would be nice to see, for adaptation of libucontext and 
other things like that.  I can handle libucontext myself if there is a 
working qemu and toolchain.

Ariadne

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Re: [musl] Port the new architecture loongarch64 to musl
  2021-05-08  5:16   ` 翟小娟
@ 2021-05-09  7:56     ` Arnd Bergmann
  0 siblings, 0 replies; 10+ messages in thread
From: Arnd Bergmann @ 2021-05-09  7:56 UTC (permalink / raw)
  To: musl; +Cc: 陈国祺

On Sat, May 8, 2021 at 7:16 AM 翟小娟 <zhaixiaojuan@loongson.cn> wrote:
>
> 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.

I can clarify what is required for merging the kernel port from my perspective:

- In order to review the kernel port on the mailing list, it needs to
be based on the latest release, and split up into
  multiple patches that provide a logical grouping.

- For the initial review, no toolchain, hardware or emulator support is needed.

- When merging the kernel, any review comments have to be addressed,
either by modifying the code, or by
  concluding that your original version was correct.

- Before the kernel is merged, I would expect at the minimum a
confirmation from the toolchain maintainers that
  the compiler can be fully merged into their following release. If
you have a patch against gcc-11 and recent
  binutils,  I can create cross-compiler binaries to build kernels and
host them along with the release builds at
  https://mirrors.edge.kernel.org/pub/tools/crosstool/.

- Validation is *not* a requirement before sending code for review,
and I would consider it a waste of your time,
  since the review tends to find issues that require invasive changes.
I expect that validation is part of your
  process for shipping software to your users, but the part I care
about for mainline support is that the source
  is maintainable in a way that lets others address problems they find.

- qemu support is definitely appreciated, but not a requirement. I'm
personally not planning to run your
   kernels in qemu as part of the review, but others might want to add
loongarch qemu to their automated
   test farms.

If you have a working kernel source tree that you need to rebase
before sending it for review,
I can offer you to take an initial look off-list to point out issues
you should address during the
rebase.

        Arnd

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Re: Re: [musl] Port the new architecture loongarch64 to musl
  2021-05-08  7:49     ` Ariadne Conill
@ 2021-05-12  9:30       ` 翟小娟
  2021-05-12 12:07         ` 罗勇刚(Yonggang Luo)
  2021-05-12 19:53         ` Ariadne Conill
  0 siblings, 2 replies; 10+ messages in thread
From: 翟小娟 @ 2021-05-12  9:30 UTC (permalink / raw)
  To: musl; +Cc: 陈国祺

Hi,
We have ported the code of libucontext for loongarch64 architecture and can be obtained from https://github.com/loongson-community/libucontext 
Currently qemu is still being tested, I will announce it as soon as it is completed.

Xiaojuan Zhai

&gt; -----原始邮件-----
&gt; 发件人: "Ariadne Conill" <ariadne@dereferenced.org>
&gt; 发送时间: 2021-05-08 15:49:50 (星期六)
&gt; 收件人: musl@lists.openwall.com
&gt; 抄送: "陈国祺" <chenguoqi@loongson.cn>
&gt; 主题: Re: Re: [musl] Port the new architecture loongarch64 to musl
&gt; 
&gt; Hello,
&gt; 
&gt; On Sat, 8 May 2021, 翟小娟 wrote:
&gt; 
&gt; &gt; Yes, we refer to mips. 
&gt; &gt; qemu plans to submit to the community in the near future. For testing and verification, we can provide physical machines or qemu.
&gt; 
&gt; The qemu patch would be nice to see, for adaptation of libucontext and 
&gt; other things like that.  I can handle libucontext myself if there is a 
&gt; working qemu and toolchain.
&gt; 
&gt; Ariadne
</chenguoqi@loongson.cn></ariadne@dereferenced.org>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Re: Re: [musl] Port the new architecture loongarch64 to musl
  2021-05-12  9:30       ` 翟小娟
@ 2021-05-12 12:07         ` 罗勇刚(Yonggang Luo)
  2021-05-12 19:53         ` Ariadne Conill
  1 sibling, 0 replies; 10+ messages in thread
From: 罗勇刚(Yonggang Luo) @ 2021-05-12 12:07 UTC (permalink / raw)
  To: Musl; +Cc: 陈国祺

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

Great, I'd like to have a try with loongarch64 architecture.
It's a neat, if possible, please reply the message in plain text format.

On Wed, May 12, 2021 at 5:30 PM 翟小娟 <zhaixiaojuan@loongson.cn> wrote:
>
> Hi,
> We have ported the code of libucontext for loongarch64 architecture and
can be obtained from https://github.com/loongson-community/libucontext
> Currently qemu is still being tested, I will announce it as soon as it is
completed.
>
> Xiaojuan Zhai
>
> &gt; -----原始邮件-----
> &gt; 发件人: "Ariadne Conill" <ariadne@dereferenced.org>
> &gt; 发送时间: 2021-05-08 15:49:50 (星期六)
> &gt; 收件人: musl@lists.openwall.com
> &gt; 抄送: "陈国祺" <chenguoqi@loongson.cn>
> &gt; 主题: Re: Re: [musl] Port the new architecture loongarch64 to musl
> &gt;
> &gt; Hello,
> &gt;
> &gt; On Sat, 8 May 2021, 翟小娟 wrote:
> &gt;
> &gt; &gt; Yes, we refer to mips.
> &gt; &gt; qemu plans to submit to the community in the near future. For
testing and verification, we can provide physical machines or qemu.
> &gt;
> &gt; The qemu patch would be nice to see, for adaptation of libucontext
and
> &gt; other things like that.  I can handle libucontext myself if there is
a
> &gt; working qemu and toolchain.
> &gt;
> &gt; Ariadne
> </chenguoqi@loongson.cn></ariadne@dereferenced.org>



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

[-- Attachment #2: Type: text/html, Size: 2126 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Re: Re: [musl] Port the new architecture loongarch64 to musl
  2021-05-12  9:30       ` 翟小娟
  2021-05-12 12:07         ` 罗勇刚(Yonggang Luo)
@ 2021-05-12 19:53         ` Ariadne Conill
  2021-05-17 11:19           ` 翟小娟
  1 sibling, 1 reply; 10+ messages in thread
From: Ariadne Conill @ 2021-05-12 19:53 UTC (permalink / raw)
  To: musl; +Cc: 陈国祺

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

Hi,

On Wed, 12 May 2021, 翟小娟 wrote:

> Hi,
> We have ported the code of libucontext for loongarch64 architecture and can be obtained from https://github.com/loongson-community/libucontext 
> Currently qemu is still being tested, I will announce it as soon as it is completed.

It looks alright, but I am wondering why makecontext is written in 
assembly.  The reason why it is written in assembly for mips had to do 
with specific peculariaties of how the MIPS64 ABI interacted with 
libucontext.  I don't see that the loongarch64 code is trying to capture 
the $gp register though.

Ariadne

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Re: Re: Re: [musl] Port the new architecture loongarch64 to musl
  2021-05-12 19:53         ` Ariadne Conill
@ 2021-05-17 11:19           ` 翟小娟
  0 siblings, 0 replies; 10+ messages in thread
From: 翟小娟 @ 2021-05-17 11:19 UTC (permalink / raw)
  To: musl; +Cc: 陈国祺

The reason for the implementation in assembly  is because I am familiar with assembly myself. I think this shows the implementation logic and final purpose of the function more  clearly than the implementation in C language.


&gt; -----原始邮件-----
&gt; 发件人: "Ariadne Conill" <ariadne@dereferenced.org>
&gt; 发送时间: 2021-05-13 03:53:01 (星期四)
&gt; 收件人: musl@lists.openwall.com
&gt; 抄送: "陈国祺" <chenguoqi@loongson.cn>
&gt; 主题: Re: Re: Re: [musl] Port the new architecture loongarch64 to musl
&gt; 
&gt; Hi,
&gt; 
&gt; On Wed, 12 May 2021, 翟小娟 wrote:
&gt; 
&gt; &gt; Hi,
&gt; &gt; We have ported the code of libucontext for loongarch64 architecture and can be obtained from https://github.com/loongson-community/libucontext 
&gt; &gt; Currently qemu is still being tested, I will announce it as soon as it is completed.
&gt; 
&gt; It looks alright, but I am wondering why makecontext is written in 
&gt; assembly.  The reason why it is written in assembly for mips had to do 
&gt; with specific peculariaties of how the MIPS64 ABI interacted with 
&gt; libucontext.  I don't see that the loongarch64 code is trying to capture 
&gt; the $gp register though.
&gt; 
&gt; Ariadne


</chenguoqi@loongson.cn></ariadne@dereferenced.org>

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-05-17 11:19 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <5f6d09a5.c3a.179460eee20.Coremail.zhaixiaojuan@loongson.cn>
2021-05-07 21:58 ` [musl] Port the new architecture loongarch64 to musl Arnd Bergmann
2021-05-08  5:16   ` 翟小娟
2021-05-09  7:56     ` Arnd Bergmann
     [not found] ` <CAE2XoE_9sQrizuiy0afA1dQdPxgOkPda_39oB9DOJN1c2FB0Cw@mail.gmail.com>
2021-05-08  5:18   ` 翟小娟
     [not found] ` <32e9f7ee-bd3c-762a-a771-2da41a8c1bb0@dereferenced.org>
2021-05-08  5:23   ` 翟小娟
2021-05-08  7:49     ` Ariadne Conill
2021-05-12  9:30       ` 翟小娟
2021-05-12 12:07         ` 罗勇刚(Yonggang Luo)
2021-05-12 19:53         ` Ariadne Conill
2021-05-17 11:19           ` 翟小娟

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ http://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git