[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a3BY=TGdGW_0CNDJKaqJaKwG=QFkin3H-pLv9ONALzmVw@mail.gmail.com>
Date: Sun, 9 May 2021 09:56:10 +0200
From: Arnd Bergmann <arnd@...nel.org>
To: musl@...ts.openwall.com
Cc: 陈国祺 <chenguoqi@...ngson.cn>
Subject: Re: Re: Port the new architecture loongarch64 to musl
On Sat, May 8, 2021 at 7:16 AM 翟小娟 <zhaixiaojuan@...ngson.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
