linux-snps-arc.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: "linux-snps-arc@lists.infradead.org"
	<linux-snps-arc@lists.infradead.org>,
	"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>
Subject: Re: ARCv2 Public PRM (was Re: [PATCH v2 00/15] glibc port to ARC processors)
Date: Thu, 6 Feb 2020 17:19:39 +0000	[thread overview]
Message-ID: <8311a699-183e-6811-cf24-3ad85ff80321@synopsys.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2001172136520.13033@digraph.polyomino.org.uk>

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

  reply	other threads:[~2020-02-06 17:19 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-30  1:25 [PATCH v2 00/15] glibc port to ARC processors Vineet Gupta
2019-01-30  1:25 ` [PATCH v2 01/15] ARC: add definitions to elf/elf.h Vineet Gupta
2019-01-30  1:25 ` [PATCH v2 02/15] ARC: ABI Implementation Vineet Gupta
2019-01-30  1:25 ` [PATCH v2 03/15] ARC: startup and dynamic linking code Vineet Gupta
2019-01-30  1:25 ` [PATCH v2 04/15] ARC: Thread Local Storage support Vineet Gupta
2019-01-30  1:25 ` [PATCH v2 05/15] ARC: Atomics and Locking primitives Vineet Gupta
2019-01-30  8:28   ` Andreas Schwab
2019-01-30 17:40     ` Vineet Gupta
2019-02-01  1:57       ` Need for arch pthread-offsets.h (was Re: [PATCH v2 05/15] ARC: Atomics and Locking primitives) Vineet Gupta
2019-02-04 10:02         ` Andreas Schwab
2019-01-30 21:04     ` [PATCH v2 05/15] ARC: Atomics and Locking primitives Joseph Myers
2019-01-30 21:35       ` Vineet Gupta
2019-01-30 21:50         ` Joseph Myers
2019-01-30 22:02           ` Vineet Gupta
2019-01-30 22:05             ` Joseph Myers
2019-01-30  1:25 ` [PATCH v2 06/15] ARC: math soft float support Vineet Gupta
2019-01-30  1:25 ` [PATCH v2 07/15] ARC: Linux Syscall Interface Vineet Gupta
2019-01-30  1:25 ` [PATCH v2 08/15] ARC: Linux ABI Vineet Gupta
2019-01-30  1:25 ` [PATCH v2 09/15] ARC: Linux Startup and Dynamic Loading Vineet Gupta
2019-01-30  1:25 ` [PATCH v2 10/15] ARC: ABI lists Vineet Gupta
2019-01-30  1:25 ` [PATCH v2 11/15] ARC: Update syscall-names.list for ARC specific syscalls Vineet Gupta
2019-01-30  1:25 ` [PATCH v2 12/15] ARC: Build Infrastructure Vineet Gupta
2019-01-30  1:25 ` [PATCH v2 13/15] build-many-glibcs.py: Enable ARC builds Vineet Gupta
2019-01-30  1:25 ` [PATCH v2 14/15] NEWS: mention ARC port Vineet Gupta
2019-01-30  1:25 ` [PATCH v2 15/15] make-syscalls.sh: fix comment referencing syscall-template Vineet Gupta
2019-01-30  2:20   ` Joseph Myers
2019-01-30  2:29 ` [PATCH v2 00/15] glibc port to ARC processors Joseph Myers
2019-01-30 18:15   ` Vineet Gupta
2019-01-30 21:19     ` Joseph Myers
2020-01-17 19:34     ` ARCv2 Public PRM (was Re: [PATCH v2 00/15] glibc port to ARC processors) Vineet Gupta
2020-01-17 21:56       ` Joseph Myers
2020-02-06 17:19         ` Vineet Gupta [this message]
2020-02-06 21:51           ` Joseph Myers
2020-02-06 22:06             ` Alistair Francis
2020-02-06 22:41               ` Vineet Gupta
2020-02-09 12:27                 ` Lukasz Majewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8311a699-183e-6811-cf24-3ad85ff80321@synopsys.com \
    --to=vineet.gupta1@synopsys.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-snps-arc@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).