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 inte
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 co
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
:
: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
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 com
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
> > complete
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, 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
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 co
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 (
: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 = time(0)
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 o
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
: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).
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 vecto
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 lis
:>
:>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 int1
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/
:> 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 fr
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
ve
21 matches
Mail list logo
