понял, что проблема возникает при вызове open()
Normally, opening the FIFO blocks until the other end is opened also.
При установке на CentOS 8, ядро 5.13.13 возникает следующая ошибка:
/usr/src/dahdi-linux-complete-3.1.0+3.1.0/linux/drivers/dahdi/opvxa24xx/callerid.c:1235:40: ошибка: в передаче аргумента 4 «proc_create_data»: несовместимый тип указателя [-Werror=incompatible-pointer-types] proc_create_data(name, 0444, base, &proc_param_fops, data); ^~~~~~~~~~~~~~~~ /usr/src/dahdi-linux-complete-3.1.0+3.1.0/linux/drivers/dahdi/opvxa24xx/callerid.c:1321:40: ошибка: в передаче аргумента 4 «proc_create_data»: несовместимый тип указателя [-Werror=incompatible-pointer-types] proc_create_data(name, 0644, base, &proc_param_off_fops, data); ^~~~~~~~~~~~~~~~~~~~
undefined reference to `boost::python::exec(char const*, boost::python::api::object, boost::python::api::object)'
$ c++filt
_ZN5boost6python4execENS0_3strENS0_3api6objectES3_
boost::python::exec(boost::python::str, boost::python::api::object, boost::python::api::object)
boost::python::str
из с-строчки. Почему ядро паникует
$ echo 'Code: 0f 7f 44 17 f0 f3 0f 7f 07 c3 48 83 fa 40 77 16 f3 0f 7f 07 f3 0f 7f 47 10 f3 0f 7f 44 17 f0 f3 0f 7f 44 17 e0 c3 48 8d 4f 40 <f3> 0f 7f 07 48 83 e1 c0 f3 0f 7f 44 17 f0 f3 0f 7f 47 10 f3 0f 7f' | scripts/decodecode
Code: 0f 7f 44 17 f0 f3 0f 7f 07 c3 48 83 fa 40 77 16 f3 0f 7f 07 f3 0f 7f 47 10 f3 0f 7f 44 17 f0 f3 0f 7f 44 17 e0 c3 48 8d 4f 40 <f3> 0f 7f 07 48 83 e1 c0 f3 0f 7f 44 17 f0 f3 0f 7f 47 10 f3 0f 7f
All code
========
0: 0f 7f 44 17 f0 movq %mm0,-0x10(%rdi,%rdx,1)
5: f3 0f 7f 07 movdqu %xmm0,(%rdi)
9: c3 retq
a: 48 83 fa 40 cmp $0x40,%rdx
e: 77 16 ja 0x26
10: f3 0f 7f 07 movdqu %xmm0,(%rdi)
14: f3 0f 7f 47 10 movdqu %xmm0,0x10(%rdi)
19: f3 0f 7f 44 17 f0 movdqu %xmm0,-0x10(%rdi,%rdx,1)
1f: f3 0f 7f 44 17 e0 movdqu %xmm0,-0x20(%rdi,%rdx,1)
25: c3 retq
26: 48 8d 4f 40 lea 0x40(%rdi),%rcx
2a:* f3 0f 7f 07 movdqu %xmm0,(%rdi) <-- trapping instruction
2e: 48 83 e1 c0 and $0xffffffffffffffc0,%rcx
32: f3 0f 7f 44 17 f0 movdqu %xmm0,-0x10(%rdi,%rdx,1)
38: f3 0f 7f 47 10 movdqu %xmm0,0x10(%rdi)
3d: f3 repz
3e: 0f .byte 0xf
3f: 7f .byte 0x7f
Code starting with the faulting instruction
===========================================
0: f3 0f 7f 07 movdqu %xmm0,(%rdi)
4: 48 83 e1 c0 and $0xffffffffffffffc0,%rcx
8: f3 0f 7f 44 17 f0 movdqu %xmm0,-0x10(%rdi,%rdx,1)
e: f3 0f 7f 47 10 movdqu %xmm0,0x10(%rdi)
13: f3 repz
14: 0f .byte 0xf
15: 7f .byte 0x7f
Linux как-то закрывает сам программы (и завершает работу ОС) "правильно" перед тем, как полностью выключиться?
выводится ошибка dlopen failed library libc.so.6 not found. Как исправить данную ошибку?
Однако я не могу получить доступ к любой из инициированных скриптом переменных в текущем процессе. Как я понимаю, это происходит потому, что скрипт выполняется отдельным процессом, а возможности экспортировать переменную на уровень выше нет.
Что нужно изменить в системе что-бы добиться такого поведения?
Или процесс создания linux headers настолько специфичен?
static struct file_operations process_sched_add_module_fops = { … proc_create(PROC_CONFIG_FILE_NAME,0777,NULL,&process_sched_add_module_fops);
proc_ops
, а не на file_operations
. Компилятор должен был бы что-нибудь сказать в этом месте, ты не читаешь его предупреждения?static ssize_t process_sched_add_module_write(struct file *file, const char *buf, size_t count, loff_t *ppos)
__user
у параметра buf
. Этот буфер приходит из юзерспейса, по этой причине ты не можешь лезть в него напрямую функцией kstrtol
. Сгенерировал приватный и публичный ключ на сервере, публичный скопировал на клиентскую машину в файл 'authorized_keys' но аутентификация как и обычно проходит по паролю.