From owner-freebsd-arch Fri May 10 10:35:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 8B34B37B401; Fri, 10 May 2002 10:35:52 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.9.1) with ESMTP id g4AHZqhU033405; Fri, 10 May 2002 10:35:52 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g4AHZpIG033404; Fri, 10 May 2002 10:35:51 -0700 (PDT) Date: Fri, 10 May 2002 10:35:51 -0700 (PDT) From: Matthew Dillon Message-Id: <200205101735.g4AHZpIG033404@apollo.backplane.com> To: John Baldwin Cc: arch@FreeBSD.org, obrien@FreeBSD.org, "Michael C. Wu" Subject: Re: syscall changes to deal with 32->64 changes. References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :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. : :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ John, I've got to disagree. You are using an extremely narrow definition of what an API change is by making the assumption that most code will just recompile without problems. I can tell you from experience that this simply is not true... especially for something like time_t. You didn't have to live through 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. I'm not an expert on GCC but I could probably do the work if nobody else wants to. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message