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

[Palmer Dabbelt]

On Mon, 10 Dec 2018 01:38:59 PST (-0800), zongbox@gmail.com wrote:
> Palmer Dabbelt <palmer@dabbelt.com> 於 2018年12月9日 週日 上午4:09寫道：
>>
>> 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.
>
> Where and how could we put the port?

I think it's OK to put it on github.

>
>>   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?
>
> Yes, I had watched the video of the topic. I totally agree your point
> and suggestion.
> I would fix the issues in this version, and then test rv32 port on
> Linux 4.21 in the future.
> Thanks to Joseph and DJ to pointed out the problems.
>
>> Is this OK with everyone?
>
> That is OK with me.

OK, sounds good!