On Wed, Jul 7, 2021 at 5:04 AM Huacai Chen [off-list ref] wrote:

On Tue, Jul 6, 2021 at 6:12 PM Arnd Bergmann [off-list ref] wrote:

quoted

3. 32-bit support: There are small bits of code for 32-bit support everywhere
   throughout the code base, but there is also code that does not look like
   it would work in that configuration. I would suggest you split out all 32-bit
   code into a separate patch, the way you have done for SMP and NUMA
   support. That way it can be reviewed separately, or deferred until when
   you actually add support for a 32-bit platform. Please also clarify which
   modes you plan to support: should every 64-bit kernel be able to run
   LA32R and LA32S user space binaries, or do you require running the same
   instruction set in both kernel and user space as RISC-V does?
   Do you plan to have MIPS N32 style user space on 64-bit kernels?

No N32 style user space in our current plan, but the 64-bit kernel is
supposed to run 32-bit applications in the near future.

Ok, sounds good. Adding compat support for a native 32-bit ABI has gotten
a lot easier over time.

On that note, what are the requirements to the kernel for supporting LBT
with aarch64/mips/x86 tasks? Does this involve handling the system calls
(ioctl in particular) for those architectures in the kernel as well, or do you
expect this to be done entirely in user space?

The same topic has come up in the past, as there are at least three projects
that need support for emulating foreign-architecture system calls (qemu,
fex and tango). If there is sufficient demand, we may end up generalizing the
kernel's compat layer to support multiple such ABIs instead of just native
and compat.

quoted

4. Toolchain sources: I see you only have binaries for an older gcc-8.3
    release and no sources so far. I assume you are already busy porting
    the internal patches to the latest gcc and will post that soon, but my
    feeling is that the kernel port should not get merged until we have a
    confirmation from the toolchain maintainers that they plan to merge
    support for their following release. We should however make sure that
    your kernel port is completely reviewed and can just get merged once
    we get there.

Toolchain is maintained by other developers, it will be open source of
course, I hope it won't be too late. :)

Right, I meant 'you' as in someone @loongson.cn, not necessarily you
personally.

quoted

5. Platform support: You have copied the underlying logic from arch/mips,
    but that still uses a method where most platforms (not the new
    "generic" version) are mutually exclusive. Since you only support
    one platform right now, it would be best to just simplify it to the point
    where no platform specific code is needed in arch/loongarch/ and
    it just works. If you add 32-bit support later on, that obviously requires
    making a choice between two or three incompatible options.

I will improve it, and I will need some help for this.

It should be mostly covered by the comments I made on the individual
comments already, but let me know if you have more specific questions.

       Arnd