From owner-freebsd-arch Fri May 3 12:55: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E8C1437B400; Fri, 3 May 2002 12:55:02 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id FAA20971; Sat, 4 May 2002 05:55:00 +1000 Date: Sat, 4 May 2002 05:56:33 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: <13810.1020419033@critter.freebsd.dk> Message-ID: <20020504054714.H8802-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 3 May 2002, Poul-Henning Kamp wrote: > If we look at bit closer, a number of other things really need the > 32->64 treatment, struct rlimit for instance. This is still > pretty trivial. struct rlimit is already 64-bits. > And then the bad one: time_t. > > The time_t change is the most intrusive since it also changes the > size of strut timespec, and logically should change the size of > struct timeval but wouldn't since the second part there is defined > as "long". This makes rusage, itimerval, pps_info_t and SVID IPC > change size and affects quite a number of syscalls. It would change the size of struct timeval on 32-bit machines, since the alignment of the "long" should be 32 bits even if longs have the correct size (2 * 32 bits). > And before anybody gets their knickers in a twist (there's a lot > of that going round these days as the doctor would say) this all > needs to be done and will be done in a backwards compatible way. > > Questions: > > 1. Are there anything else that needs to change size while we're > at it ? > > 2. Is this a good occation to create a new syscall vector for > FreeBSD 5.0 rather than embellish the existing one with even > more variations ? Depends on how long you want to delay 5.0R by ;-). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message