Message ID | 1548811555-24373-1-git-send-email-vgupta@synopsys.com |
---|---|
Headers | show |
Series | glibc port to ARC processors | expand |
In the absence of clear consensus regarding consideration of new ports to undocumented architectures (which would need to result in consensus on suitable rules on the subject to go in <https://sourceware.org/glibc/wiki/NewPorts>), and in the absence of suitable public architecture and ABI documentation, I don't intend to attempt review of this or subsequent versions of the port submission. (I am supposing that the documentation available at <http://me.bios.io/ARC_disassembly> - which in any case does not include an ABI reference - is for an architecture version too old to be sufficient for understanding and maintaining the port code as may be needed in the course of glibc maintenance.)
On 1/29/19 6:29 PM, Joseph Myers wrote: > In the absence of clear consensus regarding consideration of new ports to > undocumented architectures (which would need to result in consensus on > suitable rules on the subject to go in > <https://sourceware.org/glibc/wiki/NewPorts>), and in the absence of > suitable public architecture and ABI documentation, I don't intend to > attempt review of this or subsequent versions of the port submission. That would be really unfortunate. Your prior reviews of RFC and v1 have been immensely helpful, it would be a shame to not continue to get this privilege goinf fwd. Having said that, wheels were already set in motion after your initial request in December. The ARCv2 ABI spec was opened up quickly (and mea culpa for not referencing it v2 submission). It is now publicly accessibly at [1] The public version of PRM is being worked on, but it will take time to come to fruition. I hope you appreciate these things take time, considering where we came from - and it seems you found a workaround anyways ;-) > (I > am supposing that the documentation available at > <http://me.bios.io/ARC_disassembly> - which in any case does not include > an ABI reference - is for an architecture version too old to be sufficient > for understanding and maintaining the port code as may be needed in the > course of glibc maintenance.) Not really. It sure pertains to the predecessor ARCompact ISA, but in ARCv2 the bulk of changes were to Interrupt architecture, micro-architecture optimizations, SMP support etc, which are not relevant for glibc or general userspace coding. While the encodings etc did change, much of the baseline instruction set is pretty much the same, so ARCv2 assembly or generated code easily maps to ARCompact. I do hope this is enough for you to reconsider reviewing the code. Thx, -Vineet [1] https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/wiki/files/ARCv2_ABI.pdf
On Wed, 30 Jan 2019, Vineet Gupta wrote: > Having said that, wheels were already set in motion after your initial request in > December. The ARCv2 ABI spec was opened up quickly (and mea culpa for not > referencing it v2 submission). It is now publicly accessibly at [1] Thanks. To be clear, the description at <https://sourceware.org/glibc/wiki/NewPorts> of what should go in the summary message for a new port submission should be considered to apply to every version of that submission, so that each submission is self-contained. That is, every version of the submission should include information such as pointers to relevant manuals (in addition to whatever's appropriate about changes from the previous version of the submission). > The public version of PRM is being worked on, but it will take time to > come to fruition. I hope you appreciate these things take time, > considering where we came from - and it seems you found a workaround > anyways ;-) There are five months until the freeze for 2.30 starts (obviously the port will need its symbol versions updated for 2.30).
Hi Joseph, On 1/30/19 10:15 AM, Vineet Gupta wrote: > On 1/29/19 6:29 PM, Joseph Myers wrote: >> In the absence of clear consensus regarding consideration of new ports to >> undocumented architectures (which would need to result in consensus on >> suitable rules on the subject to go in >> <https://sourceware.org/glibc/wiki/NewPorts>), and in the absence of >> suitable public architecture and ABI documentation, I don't intend to >> attempt review of this or subsequent versions of the port submission. > > That would be really unfortunate. Your prior reviews of RFC and v1 have been > immensely helpful, it would be a shame to not continue to get this privilege goinf > fwd. > > Having said that, wheels were already set in motion after your initial request in > December. The ARCv2 ABI spec was opened up quickly (and mea culpa for not > referencing it v2 submission). It is now publicly accessibly at [1] > > The public version of PRM is being worked on, but it will take time to come to > fruition. I hope you appreciate these things take time, considering where we came > from - and it seems you found a workaround anyways ;-) The public PRM is now available and I would like you to try and access it so that any bureaucracy is out of the way before I re-post ARC port for 2.32 ! Do note you still need to register to download but that is no different than say ARM. The landing page is https://www.synopsys.com/dw/ipdir.php?ds=arc-hs44-hs46-hs48 And there in the link to actual doc is https://www.synopsys.com/dw/doc.php/ds/cc/programmers-reference-manual-ARC-HS.pdf Let me know how it goes. Thx, -Vineet
On Fri, 17 Jan 2020, Vineet Gupta wrote: > The public PRM is now available and I would like you to try and access > it so that any bureaucracy is out of the way before I re-post ARC port > for 2.32 ! Thanks! There was one technical point regarding the glibc port I raised briefly in a discussion at the end of the Cauldron in Montreal: you should consider whether it would make sense, as a new 32-bit port, to have 64-bit times and 64-bit off_t, ino_t, etc. from the start, as RV32 is doing. We don't have a specific policy for this, but it may make sense for new ports not to include ABI variants that either are, or will become, obsolescent. If you require Linux 5.1 or later for the port then all or nearly all the architecture-independent pieces required for a 32-bit port supporting only 64-bit times should be covered by the RV32 patches, which I think are quite close to being ready to go into glibc, though you'd need to watch out for any (new or existing) #ifdef conditionals that might try to use 32-bit-time syscalls if they exist (which they don't on RV32) - and that would not prevent supporting older kernel versions later if desired, as the Y2038 support gets built out (including, in particular, the support for falling back to 32-bit-time syscalls in functions for 64-bit-time interfaces).
On 1/17/20 1:56 PM, Joseph Myers wrote: > There was one technical point regarding the glibc port I raised briefly in > a discussion at the end of the Cauldron in Montreal: you should consider > whether it would make sense, as a new 32-bit port, to have 64-bit times > and 64-bit off_t, ino_t, etc. from the start, as RV32 is doing. We don't > have a specific policy for this, but it may make sense for new ports not > to include ABI variants that either are, or will become, obsolescent. I agree we should do that. > If > you require Linux 5.1 or later for the port then all or nearly all the > architecture-independent pieces required for a 32-bit port supporting only > 64-bit times should be covered by the RV32 patches, which I think are > quite close to being ready to go into glibc, though you'd need to watch > out for any (new or existing) #ifdef conditionals that might try to use > 32-bit-time syscalls if they exist (which they don't on RV32) - and that > would not prevent supporting older kernel versions later if desired, as > the Y2038 support gets built out (including, in particular, the support > for falling back to 32-bit-time syscalls in functions for 64-bit-time > interfaces). Ok I see patches in flight on the mailing list. Would it make sense for me to start off in parallel with ARC port which will take it's due course of review and rework and in that process upstream y2038 work settles down and I then rebase/switch ARC to that. Or would rather wait for upstream to settle down and then I adjust/post ? Thx, -Vineet
On Thu, 6 Feb 2020, Vineet Gupta wrote: > > If > > you require Linux 5.1 or later for the port then all or nearly all the > > architecture-independent pieces required for a 32-bit port supporting only > > 64-bit times should be covered by the RV32 patches, which I think are > > quite close to being ready to go into glibc, though you'd need to watch > > out for any (new or existing) #ifdef conditionals that might try to use > > 32-bit-time syscalls if they exist (which they don't on RV32) - and that > > would not prevent supporting older kernel versions later if desired, as > > the Y2038 support gets built out (including, in particular, the support > > for falling back to 32-bit-time syscalls in functions for 64-bit-time > > interfaces). > > Ok I see patches in flight on the mailing list. Would it make sense for me to > start off in parallel with ARC port which will take it's due course of review and > rework and in that process upstream y2038 work settles down and I then > rebase/switch ARC to that. Or would rather wait for upstream to settle down and > then I adjust/post ? I'd suggest posting patches that are on top of the RV32 ones (maybe there's a git tree with RV32 changes to current glibc that could be used), and that only support Linux 5.1 and later (so you don't need anything much of the Y2038 support beyond what's in the RV32 patches).
On Thu, Feb 6, 2020 at 1:51 PM Joseph Myers <joseph@codesourcery.com> wrote: > > On Thu, 6 Feb 2020, Vineet Gupta wrote: > > > > If > > > you require Linux 5.1 or later for the port then all or nearly all the > > > architecture-independent pieces required for a 32-bit port supporting only > > > 64-bit times should be covered by the RV32 patches, which I think are > > > quite close to being ready to go into glibc, though you'd need to watch > > > out for any (new or existing) #ifdef conditionals that might try to use > > > 32-bit-time syscalls if they exist (which they don't on RV32) - and that > > > would not prevent supporting older kernel versions later if desired, as > > > the Y2038 support gets built out (including, in particular, the support > > > for falling back to 32-bit-time syscalls in functions for 64-bit-time > > > interfaces). > > > > Ok I see patches in flight on the mailing list. Would it make sense for me to > > start off in parallel with ARC port which will take it's due course of review and > > rework and in that process upstream y2038 work settles down and I then > > rebase/switch ARC to that. Or would rather wait for upstream to settle down and > > then I adjust/post ? > > I'd suggest posting patches that are on top of the RV32 ones (maybe > there's a git tree with RV32 changes to current glibc that could be used), > and that only support Linux 5.1 and later (so you don't need anything much > of the Y2038 support beyond what's in the RV32 patches). Go for it! My working branch is here: https://github.com/alistair23/glibc/tree/alistair/rv32.next My latest RFC branch is here: https://github.com/alistair23/glibc/tree/alistair/rv32.rfc6 Alistair > > -- > Joseph S. Myers > joseph@codesourcery.com
On 2/6/20 2:06 PM, Alistair Francis wrote: >> >> I'd suggest posting patches that are on top of the RV32 ones (maybe >> there's a git tree with RV32 changes to current glibc that could be used), >> and that only support Linux 5.1 and later (so you don't need anything much >> of the Y2038 support beyond what's in the RV32 patches). > > Go for it! > > My working branch is here: > https://github.com/alistair23/glibc/tree/alistair/rv32.next > > My latest RFC branch is here: > https://github.com/alistair23/glibc/tree/alistair/rv32.rfc6 Thx a bunch Alistair. I'm rebasing my stuff on top of your next branch as it seems to have more time/y2038 code so will help shake it out as well. Thx, -Vineet
Hi Vineet, > On 2/6/20 2:06 PM, Alistair Francis wrote: > >> > >> I'd suggest posting patches that are on top of the RV32 ones (maybe > >> there's a git tree with RV32 changes to current glibc that could > >> be used), and that only support Linux 5.1 and later (so you don't > >> need anything much of the Y2038 support beyond what's in the RV32 > >> patches). > > > > Go for it! > > > > My working branch is here: > > https://github.com/alistair23/glibc/tree/alistair/rv32.next > > > > My latest RFC branch is here: > > https://github.com/alistair23/glibc/tree/alistair/rv32.rfc6 > > Thx a bunch Alistair. I'm rebasing my stuff on top of your next > branch as it seems to have more time/y2038 code so will help shake it > out as well. If it may help a bit, please also review/check the current status of Y2038 work. Some Y2038 related work (mostly for ARM32) may be also helpful as well (as some patches for RV32 also do the conversion for other architectures). https://github.com/lmajewski/y2038_glibc/commits/y2038_edge Please also find the meta layer for testing Y2038 (with some basic test suite) code on qemu-arm and Yocto/OE: https://github.com/lmajewski/meta-y2038 (it shall also be easy to extend this meta layer to add support for ARC as well). > > Thx, > -Vineet Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de