Date: Fri, 03 May 2002 11:43:53 +0200 From: Poul-Henning Kamp <phk@freebsd.org> To: arch@freebsd.org Subject: syscall changes to deal with 32->64 changes. Message-ID: <13810.1020419033@critter.freebsd.dk>
next in thread | raw e-mail | index | archive | help
We have some 32 to 64 bit changes outstanding, which are necessary to complete the UFS2 DARPA project. So far the following three have been identified as having a syscall impact: ino_t stat.st_gen statfs.<many> These are pretty trivial, it involves adding some new 64bit versions of the syscalls and corresponding data structures. 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. 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. 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 ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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?13810.1020419033>