RFC: __kernel_time_t

[Robert Millan]

On Tue, Jan 03, 2006 at 08:33:58PM +0100, Robert Millan wrote:
> On Tue, Jan 03, 2006 at 08:24:57PM +0100, Aurelien Jarno wrote:
> > On Tue, Jan 03, 2006 at 08:20:27PM +0100, Robert Millan wrote:
> > > On Tue, Jan 03, 2006 at 08:07:54PM +0100, Aurelien Jarno wrote:
> > > > 
> > > > First, you will se that our definition is wrong in case of amd64, ia64
> > > > and sparc64. Then __time_t in the kernel == __time_t in userland on all 
> > > > platforms but alpha. That's probably because alpha is the first 64-bit
> > > > port and at the time it was done, the wrong choice has been done about
> > > > the type of __time_t.
> > > 
> > > Maybe this helps:
> > > 
> > > http://lists.alioth.debian.org/pipermail/glibc-bsd-devel/2004-December/000324.html
> > > 
> > > According to Bruno, alpha's 32bit time_t won't overflow untill 2038.  I don't
> > > think anybody will care about alpha at that time, so my suggestion would be to
> > > just ignore the problem and use whatever the kernel uses.
> > 
> > What do you mean by "ignoring the problem"? If we change nothing, that's
> > mean we will keep our ugly-hack, and we will also have problems with the
> > amd64 port.
> 
> I mean getting rid of __kernel_time_t, of course.  That'll give you an ABI
> change in alpha, but who cares :)

Another option is to patch the kernel to define time_t as 64bit for alpha, then
let the change happen in kernel abi instead.

-- 
Robert Millan