Date: Mon, 2 Sep 2002 16:08:09 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@wemm.org>, hackers@freebsd.org Subject: Re: 64 bit API/ABI changes proposal for -current Message-ID: <200209022308.g82N896t038011@apollo.backplane.com> References: <20020902223634.6DFFD2A88D@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter, you are again not reading what I'm posting carefully enough.
I said very specifically that we wouldn't be using the fractional
stuff for this case.
Additionally, you are making the assumption that --unix64 and --unix32
are so different from each other that the same code cannot compile to
both targets. This is not true either. The only difference is that
a couple of types, such as time_t and ino_t, would be extended to
64 bits. The same source will be able to compile to both targets.
(in fact, our existing source can almost do this already).
Perhaps I am putting too much information out here. The idea of this
discussion is to DISCUSS, I am simply creating a starting point for
the discussion. None of this stuff is set in stone so screaming at me
telling me the whole enchilada will not work because of a few things
in here is not going to be productive. Instead you should simply
advocate that the interfering items be removed to make the rest work,
or something like that.
I'm also not sure what you mean when you say "overkill". What you
seem to be proposing is an incompatible change to the API and ABI.
Sure we can fix all the code in /usr/src, but ports are another matter.
What I am proposing does not initially interfere (or need to interfere
) with ports.
Finally, in regards to a 'working prototype', please note that what
I am proposing is designed to be an incremental process precisely
because the whole enchilada is too big to create a 'working prototype'
before committing. The project can be cut into many small incremental,
non destructive pieces which are comitted incrementally. That's the
whole point. You and others may like to do wholely working prototypes
in P4 and then smash the whole thing into -current but that isn't how
I work. So, no, I am not going to go about it that way.
-Matt
Matthew Dillon
<dillon@backplane.com>
:Matthew Dillon wrote:
:
:> Well, then what we want is a new syscall vector, duplicate libraries,
:> and a compiler option, and leave all the function names the same
:> (which means no bintime but allows us to retain everything else).
:> -current would release supporting both with the compiler option
:> defaulting to --unix32 on the IA32 and --unix64 on 64 bit platforms,
:> and then down the line the compiler option would default to --unix64
:> on all platforms, and then down the line a little more the original
:> syscall vector would become a compatibility option that most people
:> leave out.
:
:Argh! This is way overkill. It is *not* what I was advocating.
:
:The time to do this is when we bump libc's major number, not duplicating
:libraries etc. That's a worst case outcome especially when it isn't needed.
:
:It would be far less disruptive to add an additional group of 64 bit
:time aware API's that are optional and portable. Leave the standards-defined
:API's alone.
:
:For example, in your previous suggestion, you had:
: typedef int64_t time64_t;
: struct timeval64 {
: time64_t tv_sec;
: int64_t tv_frac; /* N/2^63 fractional */
: };
: #ifdef __UNIX_API64__
: #define timeval timeval64
: #endif
:
:You simply *cannot do this* and remain posix compliant on 64 bit machines.
:We do not just go and change posix api's just for the sake of leaving out a
:"64" in a name. If you are going to modify code to use tv_frac, then you
:may as well refer to it in a 'struct timeval64' and be done with it.
:I suspect there would be far less confusion if they were not named so closely
:to their standardized counterparts.
:
:Changing code to work with --unix64 on 32 bit systems becomes useless
:when we have 64 bit native systems, because we then need to un-port it..
:(remember --unix64 changes struct timeval.tv_usec to .tv_frac, so code that
:is "cleaned" to work on --unix64 will no longer compile on a native
:64 bit posix compliant environment)
:
:Maybe I'm getting all upset about nothing, but you are scaring the hell
:out of me so far.
:
:> The advantage of all of this is that the 32 bit code stays intact and
:> compatible in both source and binary forms, which means no further
:> disruption of -current, just a lot of ABI work on my part. I already
:> did a dry run of the libc changes necessary and given the chance to
:> adjust things incrementally (which can be done with this methodology),
:> it's a lot of grunt work but nothing that I couldn't do in a few weeks.
:
:Well, I'd like to see a working prototype before anything is committed.
:Changes in this area are of massive importance to the whole project, so we
:*must* get it right and agreed apon, or leave it alone. It would also be
:really good if you could get some buy-in from the other *bsd/linux folks.
:
:Cheers,
:-Peter
:--
:Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
:"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200209022308.g82N896t038011>