Re: [PATCH v4 00/10] RISC-V glibc port for the 32-bit

[Andrew Waterman <andrew at sifive dot com>]

On Sat, Dec 8, 2018 at 12:09 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Fri, 07 Dec 2018 01:51:46 PST (-0800), zongbox@gmail.com wrote:
> > Joseph Myers <joseph@codesourcery.com> 於 2018年12月4日 週二 上午2:04寫道：
> >>
> >> Could you confirm the ABI entries that would be added to
> >> <https://sourceware.org/glibc/wiki/ABIList>?
> >
> > We would need to add the ABI entries as following:
> > 32-bit, soft-float, LE: /lib/ld-linux-riscv32-ilp32.so.1
> > 32-bit, hard-float, LE: /lib/ld-linux-riscv32-ilp32d.so.1
> >
> >> Could you confirm the minimum upstream kernel version that supports 32-bit
> >> RISC-V with the syscall ABI that will remain supported long-term?  Is it
> >> 4.15, or a later version?  (If a later version, arch_minimum_kernel needs
> >> to be set accordingly.)
> >>
> > I had checked with Palmer, and Palmer would confirm this here.
>
> Sorry for the confusion.  A few of us sat down at the toolchain microconference
> at Plumbers and we decided it would be best to wait until the 32-bit Linux port
> is ready to support a 64-bit time_t ABI.  This isn't ready yet and won't be
> ready in time for the glibc freeze.
>
> The options considered were to:
>
> * Submit this port, which matches the current Linux ABI.  This has been stable
>   since 4.15.
> * Try to push all the 64-bit time_t stuff into the next releases, so Linux
>   4.21 (which is not out yet).
> * Wait until after the next glibc release and then submit the port, ideally
>   also against Linux 4.21.
>
> We all decided to wait, as if we submit this now we'll end up with a RV32I
> glibc port that's 32-bit time_t.  We'd then have to go do another 64-bit time_t
> port along with everyone else, thus making this original port obsolete -- we'd
> have to support the 32-bit time_t port forever, which seems like a headache.
>
> The plan we came up with was to instead:
>
> * Review this port as if it was to be submitted, so we can sort out the issues.
> * Produce an out-of-tree 32-bit time_t port, based on the upcoming glibc
>   release, that we can then use the bring up the port of at least one distro.
>   I know OpenEmbedded is coming up for RV32I, which would give me a lot more
>   confidence we have an actual working port.
> * Submit the port after the upcoming release in February.
> * Fix both Linux (for 4.21) and our glibc port to use a 64-bit time_t ABI,
>   which should be possible at least for all core kernel functionality.
>
> I know Zong was at Plumbers, maybe you missed the tool chain thing?
>
> Is this OK with everyone?

I support this plan.