At the risk of butting into an important thread and revealing my
total ignorance about all this stuff, I notice that NetBSD claims
to be 64 bit clean since 1.0, right down to FFS (I looked around
the NetBSD mailing lists recently for discussions about UFS2--there
didn't appear to be much
About 34 system calls need work (with time changes), approximately
16 without time changes. I've included a summary at the end.
The questions before us:
* What to do about time representation.
* Whether to create a new syscall vector or use the existing
In message [EMAIL PROTECTED], Matthew Dillon w
rites:
struct timeval64 {
time64_ttv_sec;
int64_t tv_frac;/* N/2^63 fractional */
};
We have this one already, and it's called bintime, except that it
correctly uses N/2^64
: struct timeval64 {
: time64_ttv_sec;
: int64_t tv_frac;/* N/2^63 fractional */
: };
:
:We have this one already, and it's called bintime, except that it
:correctly uses N/2^64 fractional the way binary computers prefer it.
:
:--
In message [EMAIL PROTECTED], Matthew Dillon w
rites:
: struct timeval64 {
: time64_ttv_sec;
: int64_t tv_frac;/* N/2^63 fractional */
: };
:
:We have this one already, and it's called bintime, except that it
:correctly uses N/2^64
:
:All right, I'll amend the proposal to use 2^64. the fractional
:element will be unsigned, the tv_sec will remain signed.
:
:That is exactly how bintime is defined :-)
:
: struct bintime {
: time_t sec;
: uint64_t frac;
: };
:
:If I had a
In message [EMAIL PROTECTED], Matthew Dillon w
rites:
Ok, we have an issue in regards to libc/user function visibility.
The bintime structures and functions are surrounded by __BSD_VISIBLE.
That was an attempt at preventive debrucification :-)
The question to you and to the list in
Matthew Dillon wrote:
About 34 system calls need work (with time changes), approximately
16 without time changes. I've included a summary at the end.
The questions before us:
* What to do about time representation.
* Whether to create a new syscall vector or
:Matt, I realize you have thought long and hard about this, but I want to
:make a couple of points.
:
:1) 32 bit i386 already has its fate sealed. AMD are switching to 64 bit,
:and Intel are doing the same (either x86-64 or their own 64 bit environment,
:depending on which rumors you listen to).
My original proposal, before this one, was to create a separate
ABI for all the new calls, which also means creating a duplicate
set of libraries. I'm still game to do that -- it could be controlled
by a make.conf variable and selectable via a compiler option.
If we maintain
Matthew Dillon wrote:
:4) Changing time_t to 64 bit using long long on a native 32 bit platform
:is a f*cking nightmare. I've tried this and it got very nasty very quickly.
This is not what I proposed. I proposed adding new system calls to
completely and permanently fix all of
:Well, one thing that I would not be against is a clean divorce of the
:syscall layer and libc. That then gives us the freedom to implement
:alternative API selections etc at compile time pretty easily.
:
:I just really do not want to see this sort of thing turning up:
:
: time_t foo =
Oops, let me clarify what I mean by 'duplicate libraries'. I do
*NOT* mean duping the source code, I simply mean duping the
compile run in the buildworld, one for --unix32, one for --unix64,
for 32 bit platforms. 64 bit platforms would require no library
duplication at all
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
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
Matthew Dillon wrote:
Ok, we have an issue in regards to libc/user function visibility.
The bintime structures and functions are surrounded by __BSD_VISIBLE.
The question to you and to the list in general is: what to call the
user-visible structure. 'bintime' is a cute
Peter Wemm wrote:
Matthew Dillon wrote:
:4) Changing time_t to 64 bit using long long on a native 32 bit platform
:is a f*cking nightmare. I've tried this and it got very nasty very quickly.
This is not what I proposed. I proposed adding new system calls to
completely and
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
:
: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
In message: [EMAIL PROTECTED]
Matthew Dillon [EMAIL PROTECTED] writes:
: 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.
I think that this is a worthy problem to
In message [EMAIL PROTECTED], M. Warner Losh writes:
In message: [EMAIL PROTECTED]
I think that this is a worthy problem to solve. But not for 5.0. [...]
Good thinking.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
21 matches
Mail list logo
