tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

64 bit time_t changes



Hello,

I am done with the kernel portion of the 64 bit time_t changes and I have
versioned all the system calls affected so that we can preserve system call
level compatibility (and it works! I have been running an old userland with
it and only netstat seems to be broken). I started working on userland and
I saw that there is a very large number of things that are affected:
        password
        utmp, utmpx, lastlog, wtmp
        rpc stuff
        all time and clock functions
        utime
        sigtimedwait
        mq_send and receive
        all stat stuff again
        fts again

I can do the work, but I am beginning to wonder if this is the time to
bump libc, and get rid a lot of the compat code that we've collected
through the years? We can use this to sanitize size_t across all the
platforms and do the rest of the cleanup that is mentioned in shlib_version.

What I am afraid is going to happen if we provide all this compatibility
stuff, is that:
        1. libc will bloat a lot more.
        2. since time_t is such a big abi change
           [timeval, timespec, itimer stuff, rusage, ktrace, just to mention
            a few change], if we don't bump libc, we are going to cause
            confusion with mixing 3rd party libraries that are compiled before
            and after the time_t change.

Opinions?

christos


Home | Main Index | Thread Index | Old Index