Re: 64 bit API/ABI changes proposal for -current

2002-09-03 Thread Andrew Lankford
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

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Poul-Henning Kamp
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

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread M. Warner Losh
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

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Matthew Dillon
: :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

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Terry Lambert
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

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Terry Lambert
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

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Terry Lambert
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

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Matthew Dillon
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

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Peter Wemm
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

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Matthew Dillon
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 (

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Matthew Dillon
: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)

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Peter Wemm
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

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Matthew Dillon
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

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Matthew Dillon
: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).

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Peter Wemm
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

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Poul-Henning Kamp
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

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Matthew Dillon
:> :>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

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Poul-Henning Kamp
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/

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Matthew Dillon
:> 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. : :-- :

Re: 64 bit API/ABI changes proposal for -current

2002-09-02 Thread Poul-Henning Kamp
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

64 bit API/ABI changes proposal for -current

2002-09-02 Thread Matthew Dillon
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