title: why is the open() syscall supported on some Linux systems and not others?
body: <p>I am inlining syscalls. Yes, I understand this is problematic but I have a good reason. I've tracked down my bug considerably and I'm just asking why has <em>__NR_open</em> disappeared on this arm64 Arch Linux system?</p>
  
  <blockquote>
    <p>5.0.1-1-ARCH #1 SMP Sun Mar 10 15:08:34 MDT 2019 aarch64 GNU/Linux</p>
  </blockquote>
  
  <p>Again, my code is inlining syscalls. This inlining approach works on another <em>X86_64</em> system and indeed inlining <em>mmap()</em> works on this system. However, inlining <em>open()</em> on this arm64 Arch Linux failed with <em>EFAULT</em>.</p>
  
  <p>Tracking down my bug, first, <em>__NR_open</em> is NOT even defined in this build environment. Second, regular <em>open()</em> calls <em>open64()</em> which executes an <em>svc</em> instruction with x8 set to #56, <em>__NR_openat</em>. Third, <em>__NR_open</em> is normally defined as 5 and that number has been repurposed to <em>__NR_setxattr</em>. This explains the <em>EFAULT</em>.</p>
  
  <p>Basically, <em>open()</em> gets converted into <em>openat()</em> in a user library on this system and the <em>__NR_open</em> syscall has completely disappeared, taken over by a new syscall. What I don't understand is that <em>__NR_open</em> is defined in the <a href="https://github.com/torvalds/linux/blob/master/arch/arm64/include/asm/unistd32.h" rel="nofollow noreferrer">canonical source</a> for arm64 but just not on this Arch Linux arm64 system.</p>
  
  <p>My bug fix is simple: inline <em>openat()</em> instead. But my question is why was this deleted and why is this not considered broken from a Linux POV? I'm thinking of Linus saying <em>WE DO NOT BREAK USERSPACE!</em> and I'm <em>not</em> thinking about this from a POSIX POV. Indeed <em>The Linux Programming Interface</em> doesn't cover this deletion at least not explicitly.</p>