No longer including unistd_32.h or unistd_64.h. The kernel knows what to do

The kernel knows its configuration, and will pick the correct unistd.h
No longer assuming that syscall IDs start at 0

This is a valid assumption for x86, but not for many other arches (per-EABI ARM,
MIPS, etc).
presense of __NR_socketcall is now checked more directly

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
generic __x86_64__ -> CONFIG_X86_64
Checks for split 64-bit syscall arguments are 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.
syscall table no longer checks for x86_64. Looks at the individual syscalls

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.
mmap() is allowed to have VM_EXEC

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.
Driver makes sure syscall tracepoints are enabled

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
correct the pos's size and then fix the following two compile warnings:

/Users/lgq/github/sysdig/userspace/libsinsp/filterchecks.cpp:209:11: warning: comparison of constant 18446744073709551615
      with expression of type 'uint32_t' (aka 'unsigned int') is always true [-Wtautological-constant-out-of-range-compare]
                        if(pos != string::npos)
                           ~~~ ^  ~~~~~~~~~~~~
/Users/lgq/github/sysdig/userspace/libsinsp/filterchecks.cpp:315:11: warning: comparison of constant 18446744073709551615
      with expression of type 'uint32_t' (aka 'unsigned int') is always true [-Wtautological-constant-out-of-range-compare]
                        if(pos != string::npos)
                           ~~~ ^  ~~~~~~~~~~~~
remove 'register' usage

I don't think we need to add register modifier to variables right now for this
piece of code. Otherwise it has following compile warnings:

/Users/lgq/sysdig/userspace/libsinsp/filterchecks.cpp:1044:2: warning: 'register' storage class specifier is deprecated
      [-Wdeprecated-register]
        register int dt, dir;
        ^~~~~~~~~
/Users/lgq/sysdig/userspace/libsinsp/filterchecks.cpp:1044:2: warning: 'register' storage class specifier is deprecated
      [-Wdeprecated-register]
        register int dt, dir;
        ^~~~~~~~~
/Users/lgq/sysdig/userspace/libsinsp/filterchecks.cpp:1045:2: warning: 'register' storage class specifier is deprecated
      [-Wdeprecated-register]
        register struct tm *gmt, *loc;
        ^~~~~~~~~
/Users/lgq/sysdig/userspace/libsinsp/filterchecks.cpp:1045:2: warning: 'register' storage class specifier is deprecated
      [-Wdeprecated-register]
        register struct tm *gmt, *loc;
        ^~~~~~~~~
Merge pull request #86 from dkogan/armport

[41] ARM kernel support
Merge pull request #103 from guanqun/remove-register-usage

remove 'register' usage
Merge pull request #104 from guanqun/fix-rfind-warnings

correct the pos's size and then fix the following two compile warnings:
kernel coding style: checking for NULL is not necessary
kernel coding style: proper comments
kernel coding style: spacing
kernel coding style: braces
Add Travis continous integration support

Since we can't rely on a proper kernel configuration on Travis build
machines (kernel headers, CONFIG_TRACEPOINTS, etc.), building the driver
is currently disabled.

Travis build status will be available at [1].

[1] - https://travis-ci.org/draios/sysdig

Signed-off-by: Christian Babeux <christian.babeux@0x80.ca>
Add Travis CI build status to README

Signed-off-by: Christian Babeux <christian.babeux@0x80.ca>
Fix: get_buf_pointers() declaration should be static on non-windows platform

When compiling sysdig with Clang, one might run into this error:

Linking CXX executable sysdig
../libscap/libscap.a(scap.c.o): In function `scap_readbuf':
/home/travis/build/cbab/sysdig/userspace/libscap/scap.c:488: undefined reference to `get_buf_pointers'
/home/travis/build/cbab/sysdig/userspace/libscap/scap.c:506: undefined reference to `get_buf_pointers'
../libscap/libscap.a(scap.c.o): In function `check_scap_next_wait':
/home/travis/build/cbab/sysdig/userspace/libscap/scap.c:565: undefined reference to `get_buf_pointers'
collect2: ld returned 1 exit status
make[2]: *** [userspace/sysdig/sysdig] Error 1
make[1]: *** [userspace/sysdig/CMakeFiles/sysdig.dir/all] Error 2
make: *** [all] Error 2

This can be explained by the semantic difference of the "inline" keyword
with GCC compilers vs. Clang [1]. The fix is to add the static keyword,
since this function is only used in this compile unit.

[1] - http://clang.llvm.org/compatibility.html#inline

Signed-off-by: Christian Babeux <christian.babeux@0x80.ca>