4 ms·

> statx() will serve as the year-2038-capable version of the stat() family of calls Does this seem horrible to anyone else? Why not fix stat()? Does this sysca

• Aissen 10y ago
  In Linux kernel land, the golden rule is to never break the userspace ABI. Yes, it might happen, but it's never intentional, unless there's no other choice (glaring security issue for instance).
  • gbrown_ 10y ago
    I know and understand the reasoning for this, I just don't like it. I am a BSD fan, so I indulge in a land where such ABI breaks are possible. In a fantasy land I would like to see the Linux community coming up with a way to deal with ABI breaks. Not that I think such breaks are to be taken lightly but they are sometimes necessary. Such as this case.
    • masklinn 10y ago
      The problem is because Linux is just a kernel (not an entire system like BSDs) the syscall ABI is the actual kernel API. If you break it, you break the world. On BSDs, or Window, or most every OS, there's a base "userland" library (e.g. libc) which serves as the kernel API and hides whatever ABI specific syscalls use, Linux doesn't have that.
      • gbrown_ 10y ago
        I know, I'm saying it would be nice if the Linux kernel could set up a method for breaking ABI's in a planned fashion. I'm not saying it would be easy.
        • noselasd 10y ago
          Linux has a method - which is to add the new in parallel to the old, and remove the old at a later time when it's certainly no longer needed.
          • gbrown_ 10y ago
            That's OK for Linux specific stuff but stat() is pretty standard. So downstream will end up having to clutter code to the effect of - if running on Linux use statx() else if running on non-broken platform use stat().
            • RandomBK 10y ago
              I wouldn't expect many applications to call the actual syscalls directly - most will defer to libc or some other layer of abstraction, where these differences can be hidden away.
              • gbrown_ 10y ago
                Do'h, of course!
            • masklinn 10y ago
              > That's OK for Linux specific stuff but stat() is pretty standard. The libc (~POSIX) call is "pretty standard" and uses typedef'd pseudo-abstract types (OSX's stat has been 64b optionally since 10.5 and by default since 10.6, though the 32b version seems to remain available in 10.11 by compiling with _DARWIN_NO_64_BIT_INODE), the underlying syscall is not in any way.
      • cesarb 10y ago
        That only moves the problem outwards; instead of having to keep compatibility within the syscall ABI, you have to keep compatibility within the "base userland library" ABI, which is probably much larger (for instance, printf is not a syscall).
        • masklinn 10y ago
          > That only moves the problem outwards It also moves it to a place where you can have somewhat abstracted types (so chances are the client will work with just a recompile as it picks up the updated typedef), you can much more easily prepare the transition by e.g. using various flags or even trying alternatives beforehand (for instance OSX originally added a stat64 call before before rollbacking that choice and using macros to transition stat to 64b), and you are able to stop before a completely mangled syscall is actually attempted (by checking for some version symbol which must be set if you compiled for the 64b version of the various syscalls).
    • ProblemFactory 10y ago
      stat() takes a pointer to a struct where to write its output. This struct currently has 32bit values for time. If you updated stat() to write 64bit values into a different struct, any existing program calling it with a pointer to an old struct would get garbage data (and a potential buffer overflow). Renaming the function also makes debugging easier - after statx() is in widespread use, stat() could be replaced with a placeholder that raises the SIGTRAP signal, and immediately detects epoch-unsafe programs still in use.
  • deleted 10y ago
    [deleted]
• phicoh 10y ago
  To avoid breaking backward compatibility what you typically do is allocate new system call numbers for the system calls that have the new bigger time_t. Then at some point you spin a new version of the C library (and in the case of time_t, probably lots of other libraries as well). That allows old binaries to run unchanged, as long as you retire them before 2038. The tricky part starts if you also have to keep the old libraries updated with security patches.
• mrweasel 10y ago
  Because OpenBSD already did a large part of the work, and ensuring that software in their ports tree still work (and pushing patches to upstream developers) it should require less of an effort for Linux to go the same route.
• cat199 10y ago
  We'll see what actually happens.. No direct insight, but - a.out -> ELF, glibc2, and NPTL threads radically shifted threading and required kernel/userland cooperation in the Linosphere; We now have ELF symbol versioning widely supported which should make this even easier, so I suspect there will be some sort of long-run transition period and some fun C #ifdef macro fun over the long haul - e.g. I could see this new statx() thing (which apparently has additional information) being the baseline, and then having some -DLINUX_2038 gizmo which redefines stat() in terms of this function when present, possibly with some sort of ld trickery to splice together the appropriate functions in the case of shared libraries, yadda..
• ekimekim 10y ago
  Slightly off topic, but...why "x"? I thought the normal procedure for something like this would be "stat2()" (eg. accept4())
  • aaronmdjones 10y ago
    accept4() is so-named because it takes 4 arguments (instead of the usual 3). The x here probably means extended; statx(2) doesn't take any more arguments than stat(2).