Проблема регистрации загружаемого модуля ядра в процессе инмодификации
$ $(echo {a..z})
CTRL + ALT + e
$ a b c d e f g h i j k l m n o p q r s t u v w x y z
Обратите внимание, что это расширит все расширения в командной строке. Независимо от того, где находится курсор.
С помощью этой команды (иa=this; b=that):
$ echo "$a"; $(echo {a..m}); echo "$b"
Это будет расширено:
$ echo this; a b c d e f g h i j k l m ; echo that
Изman bash:
shell-expand-line (M-C-e)
Expand the line as the shell does. This performs alias and history expansion as well as all of the shell word expansions. See HISTORY EXPANSION below for a description of history expansion.
У вашего второго printk()нет \nв конце, а у первого есть.
Кроме того, число в квадратных скобках после слова kernel:— это время безотказной работы системы в секундах, поэтому похоже, что второе сообщение фактически было сгенерировано в течение той же секунды времени, что и первое.
Мое первое предположение состоит в том, что отсутствующий разделитель строки \nзаставлял процесс, читавший буфер сообщений ядра, ждать, пока не придет новый текст, а остальную часть сообщения обрабатывал только пользователь -Демон регистрации пространства после того, как \nтретьего сообщения сообщил, что получена полная строка.
В буфере сообщений ядра (см. команду dmesg)время безотказной работы в квадратных скобках обычно является первым элементом сообщения :читаемая человеком -отметка времени, имя хоста и слово kernel:добавлен любой системой ведения журнала, которая использовалась для чтения буфера сообщений ядра и вставки сообщений ядра в поток регистрации пространства пользователя -(s ).
Итак, попробуйте добавить \nв конец второго сообщения, вот так:
printk(KERN_ALERT "This is the passed argument: %d\n", yes_no);