Date: Tue, 07 May 2002 10:33:20 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: arch@FreeBSD.ORG, Poul-Henning Kamp <phk@FreeBSD.ORG> Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <XFMail.20020507103320.jhb@FreeBSD.org> In-Reply-To: <200205070815.g478Fn180961@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07-May-2002 Matthew Dillon wrote: > 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 agree completely. > 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. Right. I would like to use the ELF_ABI_OSVERSION thingie, but according to O'Brien it violates the ELF spec to use any value other than 0. But then why does it exist if we can't use it? :( One idea being thrown about is that for the new ABI (It would be FreeBSD ABI 2) there would be a syscall at syscall 0 that would never change that could be used to select what "minor" version of the ABI you wanted to use, so if we wanted to add a new ABI at some point in the future we could stick that syscall in crt.c (or whatever the proper startup file is) to change to ABI 2.1 or 2.2 or something. However, for the current change, I think bumping the ELF OS version and adding a new ABI front-end for ABI 2 is the way to go. Another advantage of this is that if our tools handle the OS version bit properly, we can actually not have to worry about much of a flag day. Instead we can gradually add the new ABI and support for it and then just quietly throw the switch to change the default ABI in current one day. Old binaries would still run fine. The only tricky part is for libc.so since you would really need two version of it (unless we also bumped to libc.so.6 for this..) and we would need to make sure we linked to the right OSVERSION of the lib when doing runtime linking, whcih could get ugly. > 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. I agree, here, too. > 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.. I think we can gradually overhaul it internally in the kernel before we throw the switch to turn it on by default since all we would be breaking would be test binaries and not "real" ones. Once the new ABI is golden, then we would throw the switch to change the default. I'm also not sure if we shouldn't wait to do this until 6.0. > -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 -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.20020507103320.jhb>