Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 May 2002 10:35:51 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        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:  <200205101735.g4AHZpIG033404@apollo.backplane.com>
References:   <XFMail.20020510080508.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
:
: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 <jhb@FreeBSD.org>  <><  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 
					<dillon@backplane.com>


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?200205101735.g4AHZpIG033404>