On Thu, 22 Aug 2013, Thorsten Glaser wrote: > Finn Thain dixit: > > we could do other sensible things (64-bit time_t, register passing of > arguments, other legacy cleanup).
Probably adding syscalls could fix the 32-bit time_t without breaking anything (given symbol versioning in libc). Fixing everything (as in a new ABI) means simultaneous changes to kernel, compiler and libc. From an implementation point of view, a plan that requires all of that effort to happen simultaneously could be impracticable. Better perhaps to add stuff to the existing ABI/API where possible. A new ABI could then come about as a consequence of removal of baggage and optimisation (presuming a performance increase to justify it). > > >get/set_thread_area to a VDSO (as well as the atomic ops). As I > >understand it, this need not break the ABI and should be faster than > >the TLS system calls. > > It will not break the ABI, but how'd it work? > > - One kernel/user shared, readonly, page global (for time, atomic) > - One kernel/user shared page per thread (instead of process), for TLS > (and possibly random)? Whatever is easiest to cut and paste from some other architecture, I guess (notwithstanding issues like TLB limitations and the capabilities of the two kinds of MMU that we support...) Hopefully someone more knowledgeable can answer that question. Finn -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.LNX.2.00.1308221917480.5376@nippy.intranet
