Comments

Could you confirm the ABI entries that would be added to
<https://sourceware.org/glibc/wiki/ABIList>?
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.)
--
Joseph S. Myers
joseph@codesourcery.com

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.

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?

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.

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

On Sat, 2018-12-08 at 12:08 -0800, Palmer Dabbelt 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.
Yep, OE has a full RV32I port buildling and booting on QEMU.
If you have a branch you would like us to help test let me know and I
can update meta-riscv.
Alistair
> * 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?

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!

On Sat, 8 Dec 2018, Palmer Dabbelt wrote:
> * 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.
Note that if you're planning for the glibc port to use only 64-bit time_t
(like x32) rather than supporting different values of _TIME_BITS, it would
be best for it also to use only 64-bit off_t etc. - as _TIME_BITS=64 will
require _FILE_OFFSET_BITS=64, and I don't think we should have a port
that's the odd one out in supporting 32-bit offsets with 64-bit times.
--
Joseph S. Myers
joseph@codesourcery.com

On Tue, 11 Dec 2018 09:48:07 PST (-0800), joseph@codesourcery.com wrote:
> On Sat, 8 Dec 2018, Palmer Dabbelt wrote:
>
>> * 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.
>
> Note that if you're planning for the glibc port to use only 64-bit time_t
> (like x32) rather than supporting different values of _TIME_BITS, it would
> be best for it also to use only 64-bit off_t etc. - as _TIME_BITS=64 will
> require _FILE_OFFSET_BITS=64, and I don't think we should have a port
> that's the odd one out in supporting 32-bit offsets with 64-bit times.
Makes sense to me.

Palmer Dabbelt <palmer@dabbelt.com> 於 2018年12月12日 週三 上午2:09寫道：
>
> On Tue, 11 Dec 2018 09:48:07 PST (-0800), joseph@codesourcery.com wrote:
> > On Sat, 8 Dec 2018, Palmer Dabbelt wrote:
> >
> >> * 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.
> >
> > Note that if you're planning for the glibc port to use only 64-bit time_t
> > (like x32) rather than supporting different values of _TIME_BITS, it would
> > be best for it also to use only 64-bit off_t etc. - as _TIME_BITS=64 will
> > require _FILE_OFFSET_BITS=64, and I don't think we should have a port
> > that's the odd one out in supporting 32-bit offsets with 64-bit times.
>
> Makes sense to me.
I would take this to next version.