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