Hi, Arnd, On Wed, Jul 7, 2021 at 3:28 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Wed, Jul 7, 2021 at 5:04 AM Huacai Chen <chenhuacai@xxxxxxxxx> wrote: > > On Tue, Jul 6, 2021 at 6:12 PM Arnd Bergmann <arnd@xxxxxxxx> 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
