Страница 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