[41] ARM kernel support #86

… to do The kernel knows its configuration, and will pick the correct unistd.h

This is a valid assumption for x86, but not for many other arches (per-EABI ARM, MIPS, etc).

Previously we were looking at __x86_64__ to see if we had that system call. Now I directly look at __NR_socketcall, which is more portable

This is described in syscall(2). Some syscalls take 64-bit arguments. On arches that have 64-bit registers, these arguments are shipped in a register. On 32-bit arches, however, these are split between two consecutive registers, with some alignment requirements. Some require an odd/even pair while some others require even/odd. For now I assume they all do what x86_32 does, and we can handle the rest when we port those.

…scalls There were some __x86_64__ checks whose purpose wasn't entirely clear. Mostly I THINK they were meant to separate the syscalls that existed on each architecture, but this wasn't done perfectly: there were syscalls that existed, but were masked out by the #ifdef. This patch removes the check for x86_64, and checks each syscall for existence individually. It may be a good idea to do this across the board for ALL the syscalls. The C preprocessor can't quite do that I don't think, but we can generate the header we want.

The kernel driver was making sure that mmap( "/dev/sysdig0" ) was getting userspace memory with the (vma->vm_flags & VM_EXEC) flag clear. For whatever reason this is not true on ARM: VM_EXEC is set there. I can't tell why yet, but things work fine after removing this check, and it seems benign enough.

The sysdig kernel driver is mostly useless without syscall tracepoints. On ARM these were added relatively recently: in Linux 3.7. This patch explicitly checks this support exists, and refuses to build if it isn't

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[41] ARM kernel support #86

[41] ARM kernel support #86

Commits on Apr 8, 2014