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 _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
