Страница 6 из 6

Re: практикум по Linux Kernel

Добавлено: 18 мар 2015, 13:59
Olej
Olej писал(а): Всё! :
Попутно возникает вопрос: а зачем тогда вообще нужна спин-блокировка?

1. Для операций в обработчике аппаратных прерываний IRQ, когда нельзя потерять контекст выполнения, отвалившись в блокированное состояние... это да. Это то, что касается ядра системы, понятно и лежит на поверхности...

2. А в приложениях userspace? в стандарте POSIX - <pthread.h>:
pthread_spin_init ()
pthread_spin_destroy ()
pthread_spin_lock ()
pthread_spin_trylock ()
pthread_spin_unlock ()
Такое впечатление, что использование спин-блокировки в приложениях может объясняться ... только жадностью ;-) , т.к. классические блокировки, переводящие поток в блокированное состояние - накладные, требующие дёргать системный шедулер.

Ещё может быть аргументом сохранение закрепления за потоком конкретного номера процессора, и при возобновлении не возникновение необходимости синхронизации кэша процессора (если процессор поменялся). Но это сложные вопросы...

Re: практикум по Linux Kernel

Добавлено: 19 мар 2015, 10:18
Olej
Olej писал(а):Те задачи, что обсуждались здесь, и ещё некоторые вопросы и задачи - собраны в связный текст и выложены для свободного использования: Практикум по Linux Kernel (продолжение).

Возможно, этот материал будет дополняться и обновляться.
Тогда это будет делаться (обновлением ссылок) прямо на этой странице.
Выложен обновлённый (сильно) вариант этого текста + архива примеров кода + архива вариантов решения задач + сопроводительного текста-справки к решению задач (чтобы понятно было где что искать).

На сегодня там порядка 56 задач, ... в порядке упражнений в программировании модулей ядра.
Это итоговая сборка всего, что показывалось на многих страницах обсуждения здесь в теме.

Ссылка та же, страница та же ... чтобы не плодить во множестве.
Только обновились ссылки на более свежие версии файлов.
Интересующиеся могут там всё это свободно скачать.

Re: практикум по Linux Kernel

Добавлено: 19 мар 2015, 11:06
Olej
Olej писал(а): Такое впечатление, что использование спин-блокировки в приложениях может объясняться ... только жадностью ;-) , т.к. классические блокировки, переводящие поток в блокированное состояние - накладные, требующие дёргать системный шедулер.
А ещё, по числу публикаций, такое впечатление, что спин-блокировка - это какое-то любимое детище MS, родившееся в недрах Windows ... ну ещё и Intel, оптимизирующей команды под эффективность Windows.
Извечное желание MS наэкономить много-много пятаков по мелочам.
С их "критическими секциями" и другими прелестями: Spinlock:
Кроме того, в той же Windows есть разновидности мьютексов (например, общеизвестная CRITICAL_SECTION, или же FAST_MUTEX в ядре), которые сначала работают как spinlock, используя опрос значения в памяти, и только потом, по истечении большого количества опросов, переходят в ядро к блокирующему ожиданию. Такие объекты сочетают лучшие качества спинлоков (минимальная цена захвата) и мьютексов (отсутствие растраты ресурса процессора на опрос).

Re: практикум по Linux Kernel

Добавлено: 26 апр 2017, 06:42
AleksOst
Здравствуйте, Olej.
Прежде всего хочу поблагодарить вас за ваш "Практикум по модулям ядра Linux" - очень полезное пособие.
Минимум воды и максимум сути по важным практическим моментам.
Подробно и обстоятельно описаны действительно тонкие вещи, информацию по которым раньше приходилось искать по десяткам разных источников в сети - и далеко не всегда успешно.

Собственно по теме моего поста - хочу сообщить что при попытке запуска тестовой утилиты mp из архива int80 - системные вызовы возвращают ошибку EFAULT.
Если в mp.c заменить инструкцию 'int $0x80' на 'syscall' с соответствующими регистрами - то всё заработает.

Архитектура: x86_64
Ядро: 3.10.0-514.10.2.el7.x86_64
Дистр: CentOS 7.3.1611

Возможно на x86_64 начиная с определённых версий ядра 'int $0x80' больше не поддерживается?

Re: практикум по Linux Kernel

Добавлено: 29 апр 2017, 22:34
Olej
AleksOst писал(а): Собственно по теме моего поста - хочу сообщить что при попытке запуска тестовой утилиты mp из архива int80 - системные вызовы возвращают ошибку EFAULT.
Если в mp.c заменить инструкцию 'int $0x80' на 'syscall' с соответствующими регистрами - то всё заработает.

Архитектура: x86_64
Ядро: 3.10.0-514.10.2.el7.x86_64
Дистр: CentOS 7.3.1611

Возможно на x86_64 начиная с определённых версий ядра 'int $0x80' больше не поддерживается?
Скорее всего (я уже не вспомню), примеры типа низкоуровневых вызовов mp проверялись и отлаживались только на 32-бит архитектурах, поскольку там ассемблерные инлайновые вставки, то на 64-бит их нужно писать по-другому.
Но очень интересно бы было посмотреть ваш пример, полный код, который работает ... сравнить и обсудить.

P.S. Непосредственно к этой теме может быть полезным, из новых экспериментов:
1. 4 способа писать в защищённую страницу (это относительно подмены системных вызовов).
2. 4 статьи о системных вызовах Linux
1. Делаем доступным все символы ядра.
2. Модификация системного вызова.
3. Сетевые системные вызовы.
4. Добавить системный вызов.
(здесь много нового, особенно относительно сетевых системных вызовах ... connect(), accept() и т.д., и относительно их принципиальной разницы реализаций на 32 и 64 бит)

Re: практикум по Linux Kernel

Добавлено: 29 апр 2017, 22:42
Olej
AleksOst писал(а): Возможно на x86_64 начиная с определённых версий ядра 'int $0x80' больше не поддерживается?

Код: Выделить всё

   __asm__ volatile ( "int $0x80":
      "=a" (__res):
      "a"(__NR_mknod),"b"((long)(pathname)),"c"((long)(mode)),"d"((long)(dev))
   );
Я предполагаю (IMHO!), что нужно будет просто более тщательно разобраться с загрузкой 64-бит регистров, ... синтаксисом макроса online GCC для загрузки 64-бит регистров.
Команды sysenter/syscall появились достаточно поздно, в процессорах Pentium IV, если не путаю ...
А Linux, даже с достаточно поздними ядрами, работает на Pentium II и III :?:

P.S. Тем более, указанное вами ядро 3.10 - не такое уж и позднее ... и не так сильно отстоит от 2.6.42, на котором эти низкоуровневые примеры ещё работали точно ... дальше не помню. Я думаю, что проблема, скорее, с корректной загрузкой 64-бит регистров.

Re: практикум по Linux Kernel

Добавлено: 13 ноя 2019, 21:18
Olej
Очень удачная публикация, из сообщества CentOS, относительно технологий сборки ядра - Build Your Own Kernel Modules. Рассмотрены подробно все 3 (все из известных мне) альтернативные варианта сборки:
1. Building a kernel module (*.ko)
...
2. Building a kernel module using Dynamic Kernel Module Support (DKMS)
...
3. Building a kernel module rpm package (kmod)
...

Re: практикум по Linux Kernel

Добавлено: 14 ноя 2019, 21:24
Olej
С некоторых не так давних времён (постепенно с 2011г., в разных дистрибутивах) общепринятый набор команд, связанных с модулями ядра, реализуется пакетом kmod и как ссылки на утилиту kmod:

Код: Выделить всё

olej@ACER:~$ aptitude search kmod | grep ^i
i  kmod - утилиты управления модулями ядра Linux
i  libkmod2 - разделяемая библиотека libkmod
i A libmikmod3 - Portable sound library

Код: Выделить всё

olej@ACER:~$ which kmod
/usr/bin/kmod

olej@ACER:~$ kmod --help
kmod - Manage kernel modules: list, load, unload, etc
Usage:
	kmod [options] command [command_options]

Options:
	-V, --version     show version
	-h, --help        show this help

Commands:
  help         Show help message
  list         list currently loaded modules
  static-nodes outputs the static-node information installed with the currently running kernel

kmod also handles gracefully if called from following symlinks:
  lsmod        compat lsmod command
  rmmod        compat rmmod command
  insmod       compat insmod command
  modinfo      compat modinfo command
  modprobe     compat modprobe command
  depmod       compat depmod command
Ссылки:

Код: Выделить всё

olej@ACER:~$ ls -l /usr/bin/lsmod
lrwxrwxrwx 1 root root 4 фев 10  2019 /usr/bin/lsmod -> kmod

olej@ACER:~$ ls -l /sbin/modinfo
lrwxrwxrwx 1 root root 9 фев 10  2019 /sbin/modinfo -> /bin/kmod

olej@ACER:~$ ls -l /sbin/modprobe
lrwxrwxrwx 1 root root 9 фев 10  2019 /sbin/modprobe -> /bin/kmod
... ну и так далее...

Re: практикум по Linux Kernel

Добавлено: 14 ноя 2019, 21:27
Olej
Olej писал(а):
14 ноя 2019, 21:24
... ну и так далее...
Можете (при желании или при необходимости) вызывать утилиту kmod напрямую:

Код: Выделить всё

olej@ACER:~$ kmod list
Module                  Size  Used by
joydev                 24576  0
binfmt_misc            20480  1
hid_generic            16384  0
usbhid                 57344  0
hid                   135168  2 usbhid,hid_generic
zram                   28672  1
zsmalloc               28672  1 zram
vhci_hcd               53248  0
vfat                   20480  1
vboxpci                28672  0
vboxnetflt             32768  0
vboxnetadp             28672  0
vboxdrv               487424  3 vboxpci,vboxnetadp,vboxnetflt
uvcvideo              118784  0
videobuf2_vmalloc      16384  1 uvcvideo
videobuf2_memops       16384  1 videobuf2_vmalloc
videobuf2_v4l2         28672  1 uvcvideo
videobuf2_common       53248  2 videobuf2_v4l2,uvcvideo
videodev              212992  3 videobuf2_v4l2,uvcvideo,videobuf2_common
usbip_host             32768  0
usbip_core             32768  2 usbip_host,vhci_hcd
snd_usb_audio         253952  0
snd_usbmidi_lib        36864  1 snd_usb_audio
snd_rawmidi            40960  1 snd_usbmidi_lib
snd_seq_device         16384  1 snd_rawmidi
sg                     36864  0
serio_raw              16384  0
psmouse               172032  0
pci_stub               16384  1
nls_cp437              20480  1
nls_ascii              16384  1
nf_nat_pptp            16384  0
nf_nat_proto_gre       16384  1 nf_nat_pptp
nf_nat                 36864  2 nf_nat_pptp,nf_nat_proto_gre
nf_conntrack_pptp      16384  1 nf_nat_pptp
nf_conntrack_proto_gre    16384  1 nf_conntrack_pptp
nf_conntrack          172032  4 nf_nat,nf_conntrack_pptp,nf_nat_pptp,nf_conntrack_proto_gre
nf_defrag_ipv6         20480  1 nf_conntrack
nf_defrag_ipv4         16384  1 nf_conntrack
media                  45056  2 videodev,uvcvideo
lp                     20480  0
ip_tables              28672  0
x_tables               45056  1 ip_tables
fat                    86016  1 vfat
ext4                  737280  2
mbcache                16384  1 ext4
jbd2                  122880  1 ext4
fscrypto               32768  1 ext4
glue_helper            16384  0
efivarfs               16384  1
ecb                    16384  0
cuse                   16384  3
fuse                  122880  4 cuse
crypto_simd            16384  0
crc16                  16384  1 ext4
btrfs                1400832  0
libcrc32c              16384  3 nf_conntrack,nf_nat,btrfs
crc32c_generic         16384  0
xor                    24576  1 btrfs
zstd_decompress        81920  1 btrfs
zstd_compress         172032  1 btrfs
xxhash                 16384  2 zstd_compress,zstd_decompress
raid6_pq              122880  1 btrfs
autofs4                49152  2
aes_x86_64             20480  0
snd_hda_codec_hdmi     57344  1
sr_mod                 28672  0
cdrom                  65536  1 sr_mod
sd_mod                 61440  5
intel_rapl             24576  0
x86_pkg_temp_thermal    16384  0
intel_powerclamp       16384  0
coretemp               16384  0
i915                 1728512  27
kvm_intel             233472  0
kvm                   729088  1 kvm_intel
snd_hda_codec_realtek   122880  1
snd_hda_codec_generic    86016  1 snd_hda_codec_realtek
irqbypass              16384  1 kvm
crct10dif_pclmul       16384  0
ahci                   40960  4
libahci                40960  1 ahci
i2c_algo_bit           16384  1 i915
iTCO_wdt               16384  0
iTCO_vendor_support    16384  1 iTCO_wdt
crc32_pclmul           16384  0
ppdev                  20480  0
crc32c_intel           24576  5
drm_kms_helper        208896  1 i915
wmi_bmof               16384  0
snd_hda_intel          45056  6
libata                270336  2 libahci,ahci
snd_hda_codec         151552  4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek
evdev                  28672  16
snd_hwdep              16384  2 snd_usb_audio,snd_hda_codec
xhci_pci               16384  0
xhci_hcd              266240  1 xhci_pci
efi_pstore             16384  0
drm                   495616  7 drm_kms_helper,i915
ehci_pci               16384  0
ehci_hcd               94208  1 ehci_pci
ghash_clmulni_intel    16384  0
cryptd                 28672  2 crypto_simd,ghash_clmulni_intel
mei_me                 45056  0
intel_cstate           16384  0
scsi_mod              249856  4 sd_mod,libata,sg,sr_mod
intel_uncore          135168  0
r8169                  90112  0
pcspkr                 16384  0
i2c_i801               28672  0
intel_rapl_perf        16384  0
realtek                20480  1
libphy                 77824  2 r8169,realtek
efivars                20480  1 efi_pstore
lpc_ich                28672  0
snd_hda_core           94208  5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
snd_pcm               114688  5 snd_hda_codec_hdmi,snd_hda_intel,snd_usb_audio,snd_hda_codec,snd_hda_core
mei                   118784  1 mei_me
usbcore               294912  10 xhci_hcd,ehci_pci,snd_usb_audio,usbhid,snd_usbmidi_lib,uvcvideo,ehci_hcd,xhci_pci,usbip_host,vhci_hcd
usb_common             16384  3 usbip_core,usbcore,vhci_hcd
snd_timer              36864  1 snd_pcm
snd                    94208  24 snd_hda_codec_generic,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_usb_audio,snd_usbmidi_lib,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm,snd_rawmidi
soundcore              16384  1 snd
fan                    16384  0
thermal                20480  0
wmi                    28672  1 wmi_bmof
parport_pc             32768  1
parport                57344  3 parport_pc,lp,ppdev
video                  45056  1 i915
button                 16384  0
pcc_cpufreq            16384  0