Re: [PATCH 00/19] arch: Add basic LoongArch support

[Huacai Chen <chenhuacai@gmail.com>]

Hi, Arnd,

On Wed, Jul 7, 2021 at 3:28 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wed, Jul 7, 2021 at 5:04 AM Huacai Chen <chenhuacai@gmail.com> wrote:
> > On Tue, Jul 6, 2021 at 6:12 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > 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.
>
> > > 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.
Now toolchain of LoongArch is open, please take a look at it. I think
there are also something need to change. In order to reduce
compatiability problems in future, please focus on those things
interactive with Linux kernel. Thank you very much!

https://github.com/loongson/glibc/tree/loongarch_2_33
https://github.com/loongson/binutils-gdb/tree/loongarch-2_37
https://github.com/loongson/gcc/tree/loongarch-12

Huacai

>
> > > 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