On Tue, 2014-05-06 at 22:07 -0400, Theodore Ts'o wrote: [...] > One of the questions to evaluate this proposal is how many syscalls > this would take. And if we the goal is to "avoid a hard ABI break", > then that also means doing something like the Large File Support hack > (i.e., open64, read64, etc.) which is application visible. Right? > But the problem is unless you get all applications to use these > non-standard, non-POSIX interfaces --- or you need to get them to use > a magic #define, ala the LFS --- and good luck getting all > applications to do make that change, LFS is far from universally supported by applications, 17 years after it was standardised. In fact, many applications recently regressed due to a broken test for LFS in autoconf . It doesn't seem like a good example to follow. > or to get distributions to modify > their build scrpits to include that --- and then it's equivalent to a > hard ABI break, since it means time_t changes size. [...] However this is done, almost every library that includes time_t in its API will change ABI. I say 'almost' because glibc will probably use symbol versioning or mangling to maintain binary compatibility, but most library maintainers won't go to that trouble. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates