5 ms·

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

by 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.

by gbrown_ 10y ago

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.