Date: Tue, 7 May 2002 01:15:49 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Poul-Henning Kamp <phk@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <200205070815.g478Fn180961@apollo.backplane.com> References: <13810.1020419033@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
As a person who has already spent several days playing with
64 bit time_t's and associated syscalls I would say that
creating a new syscall vector for FreeBSD 5.0 (and leaving the
existing one intact for compatibility) is the correct solution.
I tried to add new syscalls to the existing vector but so many
syscalls had to be changed to support 64 bit time_t's that it
became a huge mess... so much so that I would expect the other
BSD's to cry foul on us if we tried to do it with the existing
vector. It will be far, far cleaner to simply implement an
entirely new syscall vector / ELF identifier.
In regards to other things that may need to change size: A complete
audit will have to be performed. I would be happy to take a run through.
Getting it right the first time is extremely important. A bunch of
things starting leaking out of the woodwork as I was playing around
with 64 bit time_t's. At the very least I would pad the structures
to handle things like 64 bit dev_t, ino_t, and file flags, and I would
even consider padding now 96 bit structures like timespec (on IA32 with
64 bit time_t's + nanoseconds long = 96 bits) to 128 bits across the
board. It might also be worthwhile to make uid_t, gid_t, and pid_t
64 bits to support probable future work in those areas.
In regards to the 5.0R question that comes up later in the thread...
I just don't know. I will say that creating a new syscall vector
cannot be done piecemeal... you have to get it *all* in from the
get-go or you create huge issues with things like bootstrapping new
systems and general compatibility and useability, etc..
-Matt
:We have some 32 to 64 bit changes outstanding, which are necessary
:to complete the UFS2 DARPA project.
:...
:
: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
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?200205070815.g478Fn180961>