Кое-что об устройстве ядра

Взгляд изнутри

Модератор: Модераторы разделов

Аватара пользователя
flook
Сообщения: 585
Статус: Просто flook

Кое-что об устройстве ядра

Сообщение flook »

Вот решил описать кое-какие вещи, которые, как мне кажется, интересно и полезно знать.

В основной конфигурации на i386 архитектуре ядро работает в 4Gb виртуальном адресном пространстве, из которого область выше 3Gb отдана ядру, а все остальное -- пользовательским приложениям. То есть все адреса, выше 0xC0000000 суть адреса ядра. В ядре эта "мировая константа" называется PAGE_OFFSET и до недавнего времени являлась константой в полном смысле этого слова. Нынче это уже кофигурационный параметр. Если говорится, что объект находится в ядре, то это значит лишь то, что адрес его начала больше, чем эта демаркационная линия.

Защита памяти организована на основе двух предоставляемых x86 семейством процессоров сервисов -- сегментной и страничной адресациях. Остановимся на них поподробнее.

Сегментов в первом приближении всего два -- пользовательский и ядерный. База у обоих 0x00000000, лимит -- 0xFFFFFFFF, то есть на лицо обычная flat-модель памяти, различаются дескрипторы лишь уровнем привелегий -- у ядра он максимален -- 0, у пользователя минимален -- 3. Промежуточные уровни попросту не используются. Если копать глубже, то есть в файл include/asm/segment.h, то выяснится, что на самом деле различаются еще
сегменты кода и данных для ядра и пользователя, есть еще три TLS сегмента для pthread, TSS для переключения контекстов (об этом чуть позже) и кое-что еще, но это уже не так важно для понимания происходящего.

Больше из сегментной адресации не используется ничего, зато в полной мере эксплуатируются выгоды страничной адресации. К ней и приступаем.

Ядро работает с трех-, а с версии 2.6.9 -- четырехуровневой страничной адресацией. Даже если архитектура может выдать лишь два уровня (как например i386 без PAE режима), все равно в ядре используются все четыре. Соответствующие таблицы в ядре называются pgd, pud, pmd и pte, и все примитивы по работе с ними должны быть в include/asm/pgtable.h. Именно на страницах "замешана" вся защита памяти между процессами, механизм swap и знаменитые страничный кеш и технология отображения файлов в память.

Теперь следует сказать, как все это расположено в физическом адресном пространстве, ведь не каждый компьютер может похвастать наличием физических адресов 0xC0000000 и выше...

Вся физическая память делится на две зоны -- normal и highmem. Первая зона включает в себя всю физическую память от начала до первых 800Mb (или меньше, если физической памяти меньше). В самом начале загрузки все страницы этой зоны отображаются со смещением в PAGE_OFFSET в виртуальное пространство, то есть адресу 0x00000000 соответствует виртуальный 0xC0000000 и так далее (если быть совсем честным, то несколько первых страниц пропущено для DOS). Происходит это в arch/i386/kernel/head.S и начинается комментарием "Initialize page tables", а заканчивается загрузкой cr3 регистра и включением страничной адресации.

Все объекты и код ядра лежат в первой зоне. Также страницы из нее отображаются в адресное пространство пользователя, то есть в виртуальные адреса от 0x00000000 до 0xC0000000. Страницы второй зоны, если она есть, используются в основном для пользовательских целей.

Все, что выше 800Mb, но ниже 1Gb используется ядром для выделения очень больших объектов (в основном это таблицы сетевого фильтра -- iptables) весьма хитрым образом: сначала выделяются несколько страниц из любой зоны, а затем они отображаются в эту "щель" в 200Mb, для того, чтобы получить непрерывный кусок памяти.


Все (программисты как минимум) знают, что обращение к функциям ядра происходит через системные вызовы. Многие также в курсе, что на i386 осуществляется это с помощью инструкции int 0x80. Посмотрим, что же при этом происходит.

В первую очередь, процессор переключает привилегии, которые хранятся в дескрипторе обработчика прерывания. Посмотреть на инициализацию этого обработчика, равно как и всех остальных, можно в функции trap_init(),
находящейся в файле arch/i386/kernel/traps.c. Одновременно с этом переключается стек. Процесс переключения стека -- самое интересное.

Для начала нужно коротко ознакомиться с подсистемой управления процессами. Выражаясь сухим математическим языком, все множество процессов находится во взаимно-однозначнм соответствии с множеством объектов типа struct task_struct, находящимися в ядре, а короче -- каждый процесс -- это struct task_struct. Обратимся к истории. С самых первых версий в ядре присутствует макрос current, который всегда указывает на текущий процесс, то есть тот, во время выполнения которого переключились в ядро (по системному вызову или прерыванию). Открыв include/asm/current.h ядра версии ниже 2.6, видим, что этот указатель есть ни что иное, как округленное вниз до размера двух страниц значение регистра esp. То есть каждый раз, task_struct лежит в начале (точнее в конце, так
как стек "растет вниз") яденого стека и рискует быть перетертым в результате необычайного его роста (Это действительно проблема -- весь код в ядре должен быть таким, чтобы "кушать" мало стека, то есть нерекурсивным как
минимум).

До недавних пор 8Kb (размер двух страниц) под стек и task_struct было более чем достаточно, и в 2.6 ядре Линус придумал как можно "урезать" стек до одной страницы. В первом приближении, в конец стека кладется не весь task_struct, а указатель на него. Сам taks_struct выделяется в другом месте. То, что хранится на стеке получает имя thread_info (include/asm/thread_info.h).

Адрес же нового стека хранится в единственной на все процессы TSS структуре и меняется при переключении с процесса на процесс. Как выяснилось, это быстрее, чем использовать встроенный в процессор механизм переключения
задач с полным восстановлением и сохранением регистров. Таким образом, процессор, сам того не зная, не только переключает стек, но и готовит ядру информацию о том, какой процесс выполняется в момент переключения. После завершения всех описанных манипуляций процесс входит в контекст ядра. Дальше уже идут детали, посмореть на которые можно в arch/i386/kernel/entry.S, заглянув в функцию system_call. Возврат в пользовательский код производится экраном ниже -- инструкцией iret.


Вопросы:
1. Есть ли комментарии/вопросы к прочитанному
2. Интересует ли продолжение, и если да, то о чем
В каждом из нас спит гений... и с каждым днем все крепче...
Спасибо сказали:

Аватара пользователя
Zeus
Сообщения: 694

Re: Кое-что об устройстве ядра

Сообщение Zeus »

flook писал(а):
23.02.2006 15:12
Интересует ли продолжение, и если да, то о чем

Вот и спец по ядру нашёлся :)
Может ответите вот в эту ветку?
Спасибо сказали:

Аватара пользователя
d_Sun
Сообщения: 291

Re: Кое-что об устройстве ядра

Сообщение d_Sun »

flook писал(а):
23.02.2006 15:12
Вопросы:
1. Есть ли комментарии/вопросы к прочитанному
2. Интересует ли продолжение, и если да, то о чем


По прочитанному все понятно, отлично все расписали. Ну а продолжение... Было бы интересно узнать об организации многопоточности самим ядром, поддерживаемых типах диспетчеризации и их реализации, а так же о реализации IPC в ядре :)


Zeus писал(а):
23.02.2006 15:27
Может ответите вот в эту ветку?


Да. Было бы не плохо ;) Просим! :)
Моя подпись сильно длинная :)
Спасибо сказали:

Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8255
Статус: Маньяк
ОС: Arch, CentOS, Ubuntu

Re: Кое-что об устройстве ядра

Сообщение serzh-z »

flook писал(а):
23.02.2006 15:12
2. Интересует ли продолжение, и если да, то о чем


Было бы интересно прочитать о процессе исполнения ELF-файлов. Загрузка в память, связывание библиотек (а именно - связывание с использованием PIC). Каким образом выполняется отображение разделяемых библиотек и данных в память процесса.
Спасибо сказали:

Аватара пользователя
flook
Сообщения: 585
Статус: Просто flook

Re: Кое-что об устройстве ядра

Сообщение flook »

serzh-z писал(а):
23.02.2006 17:28
flook писал(а):
23.02.2006 15:12

2. Интересует ли продолжение, и если да, то о чем


Было бы интересно прочитать о процессе исполнения ELF-файлов. Загрузка в память, связывание библиотек (а именно - связывание с использованием PIC). Каким образом выполняется отображение разделяемых библиотек и данных в память процесса.

Гм... Процесс разборки elf-заголовка, я думаю, не очень интересен (он везде описан и довольно скучен). Отображение библиотек в процесс осуществляется очевидным способом - настройкой страничных таблиц, что описано в учебниках по ассемблеру. Это рассказать? :)
В каждом из нас спит гений... и с каждым днем все крепче...
Спасибо сказали:

Аватара пользователя
flook
Сообщения: 585
Статус: Просто flook

Re: Кое-что об устройстве ядра

Сообщение flook »

Видать неинтересная тема... :unsure: d_Sun, serzh-z, не обессудьте :)
В каждом из нас спит гений... и с каждым днем все крепче...
Спасибо сказали:

Аватара пользователя
Sparky
Сообщения: 604
Статус: core dumped
ОС: Plan 9

Re: Кое-что об устройстве ядра

Сообщение Sparky »

flook писал(а):
01.03.2006 11:44
Видать неинтересная тема... :unsure: d_Sun, serzh-z, не обессудьте :)

На самом деле думаю, те, кому это интересно, сами пойдут и мануальчик полистают. Их первых так сказать рук :)
Блог
--------------------

GCS/M/MU/P/IT/E d- s: a- C++(+++) UBL++ P->-- L+++$ E- W+++$ N* o? K? w>--
O M-@ V- PS@ PE+ Y+ PGP+ t 5 X R* tv-->- b++ DI? D>+ G e+(++) h--- r+ y++
Спасибо сказали:

Nab
Сообщения: 257

Re: Кое-что об устройстве ядра

Сообщение Nab »

flook писал(а):
01.03.2006 11:44
Видать неинтересная тема... :unsure: d_Sun, serzh-z, не обессудьте :)

Что значит неинтересная тема? Она интересна сама по себе, тем более в качественном изложении...
А народ здесь собрался больше слушающий наверно :)
Не уходи, а то собрал аудиторию, все ждут продолжения, а маэстро развернулся и пошел на домашний аэродром?
Нехорошо товарищи :)

Требую продолжения банкета, ик !!! (с) Киса....
Чтобы правильно задать вопрос, нужно знать больше половины ответа...
FREESCO in Ukraine
Спасибо сказали:

Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8255
Статус: Маньяк
ОС: Arch, CentOS, Ubuntu

Re: Кое-что об устройстве ядра

Сообщение serzh-z »

Пожалуй, Sparky прав. Когда приходиться с этим столкнуться (например, при проблемах с vesafb довелось копать код в том место где выполняется запрос параметров из BIOS видюхи, ещё до распаковки остальной части ядра) - то возникают вопросы, и появляется необходимость в перерывании половины Сети.

Кстати, по пути и возник ещё вопрос - по ходу дела обратил внимание - на x86_64 загрузка выполняется аж в три этапа: реальный режим, защищённый 32-х разрядный, и только потом уже 64-х разрядный... Мне лично это было бы интересно почитать - чем вообще отличается процесс загрузки ядра от привычного 32-х разр.

А вообще - не было идеи писать подобные статьи, скажем на posix.ru - я думаю, что в форуме эти описания просто будут утеряны и незамечены?
Спасибо сказали:

Аватара пользователя
Sparky
Сообщения: 604
Статус: core dumped
ОС: Plan 9

Re: Кое-что об устройстве ядра

Сообщение Sparky »

serzh-z писал(а):
01.03.2006 13:12
А вообще - не было идеи писать подобные статьи, скажем на posix.ru - я думаю, что в форуме эти описания просто будут утеряны и незамечены?

Вот именно - а те кому надо придут и посмотрят.
Блог
--------------------

GCS/M/MU/P/IT/E d- s: a- C++(+++) UBL++ P->-- L+++$ E- W+++$ N* o? K? w>--
O M-@ V- PS@ PE+ Y+ PGP+ t 5 X R* tv-->- b++ DI? D>+ G e+(++) h--- r+ y++
Спасибо сказали:

Аватара пользователя
flook
Сообщения: 585
Статус: Просто flook

Re: Кое-что об устройстве ядра

Сообщение flook »

те, кому это интересно, сами пойдут и мануальчик полистают.

Ну, мануальчиков по устройству ядра в деталях я собо не встречал :) Как говорится this is an RTFS country
Потому и решил осветить темы, о которых как-то не пишут.

А вообще - не было идеи писать подобные статьи, скажем на posix.ru

Да это не тянет на статью, чтоб на posix.ru таскать. Это больше "мысли в слух".

на x86_64 загрузка выполняется аж в три этапа...

Я с этой архитектурой очень плохо знаком. Это надо сначала еёный мануал читать, а потом уже в код лезть.

Не уходи, а то собрал аудиторию, все ждут продолжения

Хе :) Тока как-то молча. Два человека написали и все... Вот я и решил, что неинтересно...
Ну, раз интересно, то дальше, пожалуй, про управление процессами напишу.
В каждом из нас спит гений... и с каждым днем все крепче...
Спасибо сказали:

Аватара пользователя
d_Sun
Сообщения: 291

Re: Кое-что об устройстве ядра

Сообщение d_Sun »

flook писал(а):
01.03.2006 14:20
Да это не тянет на статью, чтоб на posix.ru таскать. Это больше "мысли в слух".


Очень даже тянет... ИМХО - либо прибить тему к важным ( с чисткой соответственно ), либо flook прийдется оформлять свои "мысли в слух" в виде статей :)

Обидно вот что - в этом разделе, интересные и не тривиальные темы, как правило теряються среди мусора типа "Чем С++ в винде отличается от С++ в Linux", или "Стоит ли учить C++", "Как собрать Qt под виндовз" - и так до бесконечности :(
Моя подпись сильно длинная :)
Спасибо сказали:

Аватара пользователя
t.t
Бывший модератор
Сообщения: 7390
Статус: думающий о вечном
ОС: Debian, LMDE

Re: Кое-что об устройстве ядра

Сообщение t.t »

Поддержу. Я тоже молчал, т.к. в данный момент мне это не надо. Но в принципе интересно. И в виде статьи оформить, думаю, стОит.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Спасибо сказали:

Аватара пользователя
Sparky
Сообщения: 604
Статус: core dumped
ОС: Plan 9

Re: Кое-что об устройстве ядра

Сообщение Sparky »

Вон человек в соседнем топике просит про "устройство сети в ядре" рассказать. Вот расскажи - будет уже один благодарный слушатель :)
Блог
--------------------

GCS/M/MU/P/IT/E d- s: a- C++(+++) UBL++ P->-- L+++$ E- W+++$ N* o? K? w>--
O M-@ V- PS@ PE+ Y+ PGP+ t 5 X R* tv-->- b++ DI? D>+ G e+(++) h--- r+ y++
Спасибо сказали:

Аватара пользователя
flook
Сообщения: 585
Статус: Просто flook

Re: Кое-что об устройстве ядра

Сообщение flook »

t.t писал(а):
01.03.2006 17:11
Поддержу. Я тоже молчал, т.к. в данный момент мне это не надо. Но в принципе интересно. И в виде статьи оформить, думаю, стОит.

Ну если кто научит... :rolleyes:
В каждом из нас спит гений... и с каждым днем все крепче...
Спасибо сказали:

Аватара пользователя
t.t
Бывший модератор
Сообщения: 7390
Статус: думающий о вечном
ОС: Debian, LMDE

Re: Кое-что об устройстве ядра

Сообщение t.t »

flook писал(а):
01.03.2006 19:41
t.t писал(а):
01.03.2006 17:11
Поддержу. Я тоже молчал, т.к. в данный момент мне это не надо. Но в принципе интересно. И в виде статьи оформить, думаю, стОит.
Ну если кто научит... :rolleyes:
Нужна помощь? ;) Могу взяться: контент -- ваш, оформление -- моё. Но только не сейчас, а попозжее; сейчас времени совсем нет.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Спасибо сказали:

Аватара пользователя
flook
Сообщения: 585
Статус: Просто flook

Re: Кое-что об устройстве ядра

Сообщение flook »

t.t писал(а):
04.03.2006 20:05
flook писал(а):
01.03.2006 19:41
t.t писал(а):
01.03.2006 17:11
Поддержу. Я тоже молчал, т.к. в данный момент мне это не надо. Но в принципе интересно. И в виде статьи оформить, думаю, стОит.
Ну если кто научит... :rolleyes:
Нужна помощь? ;) Могу взяться: контент -- ваш, оформление -- моё. Но только не сейчас, а попозжее; сейчас времени совсем нет.

OK. У меня правда тоже :rolleyes: , но помаленьку разгребусь...
В каждом из нас спит гений... и с каждым днем все крепче...
Спасибо сказали:

Аватара пользователя
t.t
Бывший модератор
Сообщения: 7390
Статус: думающий о вечном
ОС: Debian, LMDE

Re: Кое-что об устройстве ядра

Сообщение t.t »

(flook @ Mar 6 2006, в 11:57) писал(а):OK. У меня правда тоже , но помаленьку разгребусь...
Договорились -- стукну, как разгребусь. Если до того времени будет материал появляться -- скидывайте сюда, потом всё вместе оформим.
¡иɯʎdʞ ин ʞɐʞ 'ɐнɔɐdʞǝdu qнεиж
Спасибо сказали:

Аватара пользователя
flook
Сообщения: 585
Статус: Просто flook

Re: Кое-что об устройстве ядра

Сообщение flook »

Вот немного по управлению процессами.

Управление процессами

Как уже было сказано, каждому процессу соответствует две структуры:
struct task_struct и struct thread_info. Первая является
хранилищем всей информации о процессе, а вторая -- его стеком уровня
ядра.

Все процессы подвязына в общий список, начинающийся на init-е,
у которого есть выделенная структура -- init_task. Процедура
создания этого процесса весьма проста -- после инициализации основных
подсистем ядра "естесственным" путем, то есть вызовом fork,
создается новый процесс, а его "родитель" вваливается в бесконечный
цикл и после первого же прерывания уходит со сцены -- планировщик,
не имея под рукой соответствующей task_struct никогда не
переключается на этот код. А новый (и пока единственный) процесс
после поднятия всех остальных частей ядра (преимущественно драйверов)
делает, что должен -- зовет execve поочереди на несколькох
"стандартных" вариантах init-а, включая /sbin/init.

Теперь несколько слов об идентификаторах процессов, которых у них
множество -- номер процесса, номер группы, номер сесси и т.д. Все
id-ы оформлены как отдельные структуры (объекты) и сложены в один
большой хеш, так что поиск процесса по номеру довольно быстр.

В работе с идентификаторами зарыто главное отличие процессов от
потоков. Остановимся подробнее. Потока "в полном смысле этого слова"
в Linux нет. Поток для ядра -- это процесс, который делит адресное
пространство с каким-либо другим процессом, а также (и это чуть ли
не самое важное) -- имеет кого-то еще в свое группе, то есть у них
одинаковый номер группы.

Пощупать все это можно посморев на три системных вызова:

sys_getpid: этот должен возвращать идентификатор процесса, но
на самом деле возвращает номер группы, чтобы потоки видели себя как
один процесс.

sys_gettid: этот должен возвращать идентификатор потока, но
на самом деле возвращает pid, чтобы потоки все-таки как-то
различались.

sys_clone (расширенная версия sys_fork): этот вызов
принимает, помимо прочего, флаги, указывающие на то, что собственно
клонировать. Самыми интересными являются флаги CLONE_VM и
CLONE_THREAD. Первый указывает на то, что потомок будет иметь
общее с родителем адресное пространство (читай -- одну и ту же
страничную таблицу), а второй -- на то, что у потомка на будет создан
свой уникальный номер группы. Клонирование процесса с ними двумя как
раз порождает поток.

Описанная особенность clone показывает одну важную вещь -- потоки
все-таки являются полноценными процессами, то есть они организованы
между собой в дето-родительскую иерархию и ядро не делает больших
различий между ними. Исключением является код, отвечающий за доставку
сигналов. Он снабжен огромным количеством подпорок и количество
изменений, вносимых в него от версии к версси свидетельствеут о том,
что такая архитектура видимо является не совсем удачной.

Особенности реализации

Здесь хочется остановиться на двух интересных моментах (точнее на трех,
но про то, как устроен current я уже рассказывал), а именно на
переключении между процессами и на начале жизни нового процесса. Поскольку
второе основано на первом -- начнем с процесса переключения.

Переключение процессов происходит при вызову функции context_switch
из schedule. Других путей нет. Сама же функция schedule может
быть вызвана в первом приближении в двух случаях -- когда процесс сам
добровольно отпускает процессор, или когда ядро решает, что пора бы
переключиться: так называемое "вытеснение" или по-английски "preemtion''.
Следует заметить что вытеснение было в Linux с самого его рождения.
Preemptive kernel, появившийся в 2.6 ядре это лишь расширение старой схемы.
Раньше вытесниться процесс мог лишь выполняясь в контексте пользователя,
теперь же вытесниться может так же и ядерный код.

Итак context_switch. Сначала происходят манипуляции с адресным
пространством, о которых можно долго говорить, но интересующая нас
часть наступает в конце этой функции -- зовется switch_to. Это
платформо-зависимая функция и на i386 происходит следующее.

Как уже известно процесс и стек -- это одно и то же, значит меняется регистр
esp т.е. переключается информация о процессе, и если с ядерной информацией
все относительно понятно -- просто используется другой task_struct, то
с процессорной информацией -- регистрами -- все гораздо интереснее. Сегментные
регистры не изменяются, так как у ядра на все процессы общие сегменты. Регистры
общего назначения оставлены на попечение компилятора -- согласно C calling
convention состояние этих регистров при вызове функции может не сохраняться,
чем ядро и пользуется. Однако регистры esi и edi согласно этой самой
конвенции должны сохранять свои значения -- поэтому они сохраняются на стеке.
Остался регистр eip -- значение этого регистра явно изменить нельзя,
поэтому Linux поступает просто -- он хранит это значение на стеке так, чтобы
первый же ret попал на него, и вернулся в context_switch.

Ответ на вопрос "почему не используется аппаратное переключение задач"
звучит примерно так. Во-первых нет смысла переключать все регистры, т.к.
переключение задач не всегда означает переключение адресного пространства,
то есть регистра cr3, а это очень долгая операция, а, во-вторых,
ручное переключение ничуть не медленне, зато дает место для маневров.

Теперь про рождение нового процесса. Понятно, что он начнет исполняться как
только планировщик (читай schedule) выберет его для исполнения. При
этом, естественно, позовется context_switch, который проглотит значение
eip, лежащее на новом стеке. Ясно также, что "первые слова", которые
должен произнести новый процесс явно не те, из которых состоит хвост функции
schedule, поэтому для новых процессов в функции copy_thread значение
eip для стека выставляется на функцию ret_from_fork.

Соответственно, если что неясно расписал - комментарии уместны.
Поскольку я тут поднял и не осветил две темы - это управление адресными пространствами и работа schedule, то наверное следующими их опишу. Ну или - ваши пожелания...
В каждом из нас спит гений... и с каждым днем все крепче...
Спасибо сказали:

iAm
Сообщения: 220
ОС: Gentoo

Re: Кое-что об устройстве ядра

Сообщение iAm »

Класс!! Еще по теме ядра, пожалуйста. :)
Спасибо сказали:

Sfunx
Сообщения: 47

Re: Кое-что об устройстве ядра

Сообщение Sfunx »

Вопрос - как ядро работает с памятью в системах БЕЗ MMU ?
То есть там где процессор аппаратно не поддерживает виртуализацию памяти ?
Например ARM7T процессоры и ucLinux ?
Спасибо сказали:

Аватара пользователя
flook
Сообщения: 585
Статус: Просто flook

Re: Кое-что об устройстве ядра

Сообщение flook »

Sfunx писал(а):
15.03.2006 09:22
Вопрос - как ядро работает с памятью в системах БЕЗ MMU ?
То есть там где процессор аппаратно не поддерживает виртуализацию памяти ?
Например ARM7T процессоры и ucLinux ?

Точно также как и с MMU. Просто "страницы" всегда в памяти. Код, отвечающий за "подпорки" для no-mmu лежит в mm/nommu.c. Но это я подробно постараюсь описать когда созрею на опус по memory management. Тема огромная :)
В каждом из нас спит гений... и с каждым днем все крепче...
Спасибо сказали:

Sfunx
Сообщения: 47

Re: Кое-что об устройстве ядра

Сообщение Sfunx »

flook писал(а):
15.03.2006 10:44
Точно также как и с MMU. Просто "страницы" всегда в памяти. Код, отвечающий за "подпорки" для no-mmu лежит в mm/nommu.c. Но это я подробно постараюсь описать когда созрею на опус по memory management. Тема огромная :)


Дело в том, что вопрос для меня непраздный.
Я сумел откомпилировать ядро 2.0 под процессор AT91M55800. Это процессор с ARM-ядром 32МГц частоты, памяти 1Мбайт пока... В общем ядро работает, приложения пускаются.

Ньюанс - elf-формат не поддерживается ядром, только flt. Это не проблема само по себе.
НО! Нет в ядре 2.0 поддержки разделяемых библиотек в этом формате.

Но мне хочется засунуть туда ядро 2.6 (правда памяти допаять надо до 4х МБ), в котором есть поддержка shared-librery в формате flt.

Потому интересуюсь активно.
Спасибо сказали:

iAm
Сообщения: 220
ОС: Gentoo

Re: Кое-что об устройстве ядра

Сообщение iAm »

Скажите, пожалуйста, уважаемый flook - а Вы действительно настолько хорошо разбираетесь в ядре Linux, что сможете описать любой момент его работы, и полностью понимаете что, как и для чего нужен тот или иной отрывок кода? :)
Просто любопытно. :)
Спасибо сказали:

Аватара пользователя
flook
Сообщения: 585
Статус: Просто flook

Re: Кое-что об устройстве ядра

Сообщение flook »

iAm писал(а):
16.03.2006 15:20
Скажите, пожалуйста, уважаемый flook - а Вы действительно настолько хорошо разбираетесь в ядре Linux, что сможете описать любой момент его работы, и полностью понимаете что, как и для чего нужен тот или иной отрывок кода? :)
Просто любопытно. :)

Что-то не верится что просто... Не доверяете тому что прочли? :)

Sfunx писал(а):
16.03.2006 09:13
flook писал(а):
15.03.2006 10:44

Точно также как и с MMU. Просто "страницы" всегда в памяти. Код, отвечающий за "подпорки" для no-mmu лежит в mm/nommu.c. Но это я подробно постараюсь описать когда созрею на опус по memory management. Тема огромная :)


Дело в том, что вопрос для меня непраздный.
Я сумел откомпилировать ядро 2.0 под процессор AT91M55800. Это процессор с ARM-ядром 32МГц частоты, памяти 1Мбайт пока... В общем ядро работает, приложения пускаются.

Ньюанс - elf-формат не поддерживается ядром, только flt. Это не проблема само по себе.
НО! Нет в ядре 2.0 поддержки разделяемых библиотек в этом формате.

Но мне хочется засунуть туда ядро 2.6 (правда памяти допаять надо до 4х МБ), в котором есть поддержка shared-librery в формате flt.

Потому интересуюсь активно.

Ну, детально я в тот код не лазил пока. Если будет время - залезу и опишу отдельно про NOMMU.
В каждом из нас спит гений... и с каждым днем все крепче...
Спасибо сказали:

iAm
Сообщения: 220
ОС: Gentoo

Re: Кое-что об устройстве ядра

Сообщение iAm »

flook писал(а):
16.03.2006 19:21
Что-то не верится что просто... Не доверяете тому что прочли? :)


Да нет, доверяю. :) Просто мне вот интересно: Вы открываете какой-нибудь *.c, и понимаете, что в нем к чему и для чего. :)
Спасибо сказали:

Аватара пользователя
d_Sun
Сообщения: 291

Re: Кое-что об устройстве ядра

Сообщение d_Sun »

iAm писал(а):
17.03.2006 07:38
Да нет, доверяю. :) Просто мне вот интересно: Вы открываете какой-нибудь *.c, и понимаете, что в нем к чему и для чего. :)


Думаю все чуточку сложнее :)
Моя подпись сильно длинная :)
Спасибо сказали:

Аватара пользователя
flook
Сообщения: 585
Статус: Просто flook

Re: Кое-что об устройстве ядра

Сообщение flook »

iAm писал(а):
17.03.2006 07:38
flook писал(а):
16.03.2006 19:21
Что-то не верится что просто... Не доверяете тому что прочли? :)


Да нет, доверяю. :) Просто мне вот интересно: Вы открываете какой-нибудь *.c, и понимаете, что в нем к чему и для чего. :)

Ежели один человек построил, другой завсегда разобрать сможет" ©
То же справедливо и для программ... ;)
В каждом из нас спит гений... и с каждым днем все крепче...
Спасибо сказали:

Аватара пользователя
Asgard
Сообщения: 215
Статус: North Valfader

Re: Кое-что об устройстве ядра

Сообщение Asgard »

flook
а какие вообще доки/книги можешь посоветовать почитать по ядру?
мне пропагандировали такую связку:
Understanding Linux Kernel 2nd -> Linux Kernel Development 2nd -> Linux Device Drivers 3rd

сейчас пытаюсь асиливать Understanding Linux Kernel, но процесс, мягко говоря, идёт туго, ибо книга мегазанудная и при её чтении меня постоянно клонит в сон. честно говоря, вообще не могу понять за что её все так любят агитировать... в общем, есть какие-то более удачно написанные альтернативы, излагающие тот же матереал, скажем, менее занудно? или я слишком многого хочу? =)
sator arepo tenet opera rotas ;)
------------------------------------------------------------
LJ
Спасибо сказали:

Аватара пользователя
flook
Сообщения: 585
Статус: Просто flook

Re: Кое-что об устройстве ядра

Сообщение flook »

Asgard писал(а):
18.03.2006 12:19
flook
а какие вообще доки/книги можешь посоветовать почитать по ядру?
мне пропагандировали такую связку:
Understanding Linux Kernel 2nd -> Linux Kernel Development 2nd -> Linux Device Drivers 3rd

сейчас пытаюсь асиливать Understanding Linux Kernel, но процесс, мягко говоря, идёт туго, ибо книга мегазанудная и при её чтении меня постоянно клонит в сон. честно говоря, вообще не могу понять за что её все так любят агитировать... в общем, есть какие-то более удачно написанные альтернативы, излагающие тот же матереал, скажем, менее занудно? или я слишком много хочу? =)

По своему опыту могу сказать, что все, что есть по ядру, либо уже устарело, либо написано чересчур поверхностно - без привязки к коду, либо написано в штатах, а там им платят за толщину книги, так что воды там - 70% и более. Есть, правда, отдельные доки про разные части системы (mm, scheduler, net), но их искать нужно, и они мелкие.

Я как-то разбирался по долгу службы с работой VFS в 2.6.8.1, а еще точнее - с dentry cache. Так вот, ища описания оного, набрел на интересную фразу:
If you can help getting the documentation out of these guys, you've got a *lot* of thanks from a lot of people. As it is, it's RTFS country. (http://kerneltrap.org/node/3749)

После этого я забил на поиск доков :) и наконец-то понял своего начальника, который мне в свое время сказал "лучше то время, которое ты тратишь на google, потрать на вникание в код". Он был прав ^_^
А те вещи, которые я описал - я вообще нигде не встречал ( :rolleyes: на правах рекламы), видимо считается, что это и так понятно...
В каждом из нас спит гений... и с каждым днем все крепче...
Спасибо сказали: