Olej писал(а):
- пропустить весь раздел "Внешние интерфейсы модуля" ... в том числе и подраздел "Сеть"... -
это самая старая часть текста (она готовилась в большом цейтноте под проведение занятий, по принципу: что успел - то и будет);
- пропустить весь раздел "Внутренние механизмы ядра" - там хоть и много интересного, но а). это копание в мелочах, в API ядра, б). нечто подобное можно почитать (более-менее) и в других местах... (это тот материал, который обязательно нужно было прочитать в лекциях);
- пропустить весь раздел
"Обслуживание периферийных устройств" - потому что это самый слабый раздел текста, а что можно вообще выудить и говорить об вещах так сильно архитектурно отличающихся?
- и сразу смотреть раздел "Расширенные возможности" + к нему примеры: а). такого вы точно
нигде не почитаете, б). многие вещи там неожиданные и даже спорные в). всё это совершенно свежие результаты и это
самое интересное для обсуждения.
Я только прочитал это сообщение, но дело в том что я уже сделал почти всё наоборот )))
В процессе чтения книги у меня возникли некоторые потребности, а именно - потребность в отладке модулей. Я заинтересовался этим вопросом, так как постоянно сталкиваюсь с тем, что при частых модификациях кода модуля (добавление, удаление управляющих и отладочных конструкций) много времени уходт на вставку/удаление диагностических сообщений + иногда дела идут так плохо (например при исследовании механизма read_proc_t) что уже отладочные сообщения не помогают
. Отсюда, решил рассмотреть ассортимент способов отладки ядра и выбрать для себя наиболее подходящую. Также хочу уйти от пагубной привычки разрабатывать на хостовой системе (удобно, быстро но опасно). Прочитал 9 раздел, но этим не ограничился - вспомнил что у меня есть
"Debugging
Linux Systems" Sreekrishnan Venkateswaran (автор книги Essential Linux Device Drivers)
http://www.amazon.com/Debugging-Linux-S ... B002WY31JE. Её читаю.
Вобщем хочу настроить себе отладочную среду, причём в качестве target platform выбрал ARM так как в реальных разработках модули создаются под embedded архитектуры и отлаживать это всё на Qemu (вобщем handmade вариант eclipse среды для Android).
Кстати, в выщеуказанной книге нашёл пару экзотических вариантов отладки ядра о которых ранее даже не слышал - Kernel Probes (Kprobes, Jprobes), Kexec, Linux Trace Toolkit.
Ну и решил освежить в памяти различные структуры данных ядра (списки, очереди) и механизмы синхронизации - так как они часто в коде встречаются. Так что как видите - я пошёл от обратного... Но раздел о котором вы говорите (он у вас, кстати, называется "Более экзотические возможности") как только закончу с настройкой отладочной среды - сразу изучу