Skip to content

Instantly share code, notes, and snippets.

@GBuella
Last active April 21, 2017 17:51
Show Gist options
  • Save GBuella/60431e5b877b886d1cc3052d7286be16 to your computer and use it in GitHub Desktop.
Save GBuella/60431e5b877b886d1cc3052d7286be16 to your computer and use it in GitHub Desktop.
syscall_intercept briefing
Goal: make file operations faster!
Assumption:
One bottleneck is the block I/O layer in the kernel.
We suspect, that pmem file operations can be faster by avoiding said layer ( might turn out to be false, we'll see ).
One can implement a file system either using the block IO layer, or above it - the only way
to implement it above it is to not use the kernel at all.
File operations on a regular rainy Monday morning:
/------------\
|Application |
\------------/
|
|
/----------\
|libc |
\----------/
|
| <- Skipping Block device layer ?
|
/-----------\
|kernel |
| |
|-----------|
| VFS |
| \ |
| FS | <- using Block device layer
| \ |
| Block IO|
\-----------/
File operations while using hijacked syscalls:
/------------\
|Application |
\------------/
|
|
/----------\
|libc |
\----------/
|
|
/----------\
|pmemfile |
\----------/
In order to hijack file operations going through libc, one needs to convince libc to
use libpmemfile instead of calling the kernel. This is where the syscall intercepting
library comes into the picture.
https://github.com/marcinslusarz/nvml/tree/pmemfile.v12
See src/libsyscall_intercept/README.md and src/examples/libsyscall_intercept
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment