On Thu, Oct 18, 2018 at 10:36:45AM +0200, Arnd Bergmann wrote: > On Thu, Oct 18, 2018 at 6:11 AM Guo Ren <ren_...@c-sky.com> wrote: > > > > On Wed, Oct 17, 2018 at 05:58:46PM +0200, Arnd Bergmann wrote: > > > On Tue, Oct 16, 2018 at 4:58 AM Guo Ren <ren_...@c-sky.com> wrote: > > > > > > > > This is the 9th version patchset to add the Linux kernel port for > > > > C-SKY(csky) based on linux-4.19-rc3. > > > > > > > > There are only a few changes between V8 patchset. Hope it could be > > > > merged into linux-4.20 and I'm very grateful for any help. > > > > > > I've gone through the entire series once more and saw no show-stoppers. > > > The last patch looked like it introduced a bug, but with that one dropped, > > > I'm happy for the architecture to get merged, unless anyone else > > > has any last-minute concerns. (Alternatively, explain why I'm wrong > > > and the code works correctly, of course). > > Ok and thx for the job of csky subsystem. > > > > > > > > I'd appreciate having someone else take another look at the signal > > > handling code, the atomics, and the DT bindings and provide another > > > Ack for those. > > > > > > The remaining open question is about the 32-bit time_t interfaces. > > > With 4.20, I did not manage to get the required system calls in place > > > for using 64-bit time_t in a new architecture, so you will at least > > > start out using 32-bit time_t and likely have to keep supporting > > > that going forward, unless we decide to break the ABI here later > > > on .This is something we normally don't do, but we might make > > > an exception here, under the assumption that there are no > > > existing users with the ABI. We can debate that once we get there. > > We support uclibc-ng and glibc. > > > > 1. For uclibc-ng, linux-4.20 could run with it. > > > > 2. For glibc, Maybe we could support 32-bit + 64-bit time_t with > > KERNEL_VERSION, or just only 64-bit then linux-4.20 couldn't work with > > the csky first glibc release. > > Yes, it is always an option to make glibc more restrictive than the kernel. > We could also just make it a configuration option in the kernel whether > the system calls are provided, so they don't use memory for the > implementation. Ok. > You will probably want musl support at some point. musl-1.x always > uses 32-bit time_t today, but musl-2.x will use the 64-bit interfaces, > so just waiting a bit will probably make it work out for you. Thx for the tips, we'll consider musl in the future.
Best Regards Guo Ren
