Date: Sat, 4 May 2002 05:56:33 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Poul-Henning Kamp <phk@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <20020504054714.H8802-100000@gamplex.bde.org> In-Reply-To: <13810.1020419033@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020504054714.H8802-100000>