Исправление mittorn, (текущая версия) :
Можно. Про .so не уверен, можешь попробовать. Сделать статическую библиотеку (.a) - то же самое, что дописать в код.
И вообще используй syscall для такой функции, это стабильнее.
Там вся функция - вызов syscall.
Не забудь прочитать man 2 syscall:
Требования, зависящие от архитектуры
Каждый ABI архитектуры имеет свои собственные требования по передаче
аргументов системного вызова в ядро. Для системных вызовов, имеющих
обёртку в glibc (большинство системных вызовов), копирование аргументов
в правильные регистры с учётом архитектуры выполняется в самой glibc.
Однако при выполнении системного вызова через syscall(), вызывающий сам
должен учитывать особенности архитектуры; чаще всего это относится к
32-битным архитектурам.
Например, на архитектуре ARM Embedded ABI (EABI) 64-битное значение
(long long) должно быть выровнено по чётной паре регистров. То есть,
при использовании syscall() вместо обёрточной функции glibc системный
вызов readahead() на ARM вызывался бы с учётом EABI следующим образом:
syscall(SYS_readahead, fd, 0,
(unsigned int) (offset >> 32),
(unsigned int) (offset & 0xFFFFFFFF),
count);
Так как смещение аргумента 64 бита, и первый аргумент (fd) передаётся в
регистре r0, вызывающий должен разделить и выровнять 64-битное значение
так, чтобы оно передавалось в паре регистров r2/r3. Это выполняется
вставкой пустого значения в r1 (второго аргумент 0).
Подобные сложности можно видеть на MIPS с O32 ABI, на PowerPC с
32-битным ABI и на Xtensa.
Это относится к системным вызовам fadvise64_64(2), ftruncate64(2),
posix_fadvise(2), pread64(2), pwrite64(2), readahead(2),
sync_file_range(2) и truncate64(2).
Исходная версия mittorn, :
Можно. Про .so не уверен, можешь попробовать. Сделать статическую библиотеку (.a) - то же самое, что дописать в код.
И вообще используй syscall для такой функции, это стабильнее.
Там вся функция - вызов syscall.