Date: Fri, 10 May 2002 17:40:07 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Matthew Dillon <dillon@apollo.backplane.com>, John Baldwin <jhb@FreeBSD.ORG> Cc: arch@FreeBSD.ORG, obrien@FreeBSD.ORG, "Michael C. Wu" <keichii@iteration.net> Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <p0511175fb901c727a3cc@[128.113.24.47]> In-Reply-To: <200205101735.g4AHZpIG033404@apollo.backplane.com> References: <XFMail.20020510080508.jhb@FreeBSD.org> <200205101735.g4AHZpIG033404@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:35 AM -0700 5/10/02, Matthew Dillon wrote: >John Baldwin wrote: >: >: It's not one that other source needs to be changed for though. >: It's not like you've changed the prototypes of functions. >: Instead, you've changed the binary representation of certain >: types. We don't need to use the old ABI's for vendor code >: like Michael suggested because vendor code will compile just >: fine with the newer one. > > [...] the off_t change that occured when 64 bit cpu's > started hitting the mainstream UNIX world. It was *NASTY*. > > time_t is going to be almost as nasty. Even many of our > current utilities, for example those that embed time_t in > data streams or data files, will either break or become > incompatible with their brethren. > > This isn't a matter of brute-forcing the change. There is > just too much stuff out there to brute-force. All I am > suggesting is that we take the capabilities that we already > have to add to the compiler and extend them out to userland > as an option. It helps us, and it helps ports. The more I think about this, the more I think Matt's suggestion is a prudent one. There is still plenty of code which thinks that size_t is 'int', or uses size_t when it really should be using offset_t. The code "works" mainly because we rarely have really large files. Who knows how much code we have, both in the base system and in all the ports, which makes invalid assumptions about time_t, or of some of the other types that might be changed with this new syscall vector. > I'm not an expert on GCC but I could probably do the work > if nobody else wants to. Of course, the sticky question is that we're also in the middle of a major change in the gcc world, so I don't know how disruptive it would be to try and do these changes in about the same timeframe. And certainly the latest and greatest gcc is critical to a good 5.0-release. Still, if we were going to "do it right", I think it does make more sense to allow the ABI's to co-exist, instead of trying to make a hard cutover. If someone does have a problem with a port, it would be nice to just recompile with "the old API" and see that effects the problem. Perhaps we could volunteer Matt to at least look into the idea a bit more, without making any actual changes yet, just to see how hard it would be to do this. That work should be unrelated to the actual syscall change, so looking into this should not slow down that project. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu 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?p0511175fb901c727a3cc>