Где находится task list? (where is task list?)

[andreas90]

Читаю Роберта Лава "Разработка ядра Linux". В разделе "Управление процессами" написано, что ядро хранит информацию обо всех процессах в двухсвязном списке task list. Вопрос - где он находится? Хочу на него посмотреть.

[Uncle_Theodore]

Читаю Роберта Лава "Разработка ядра Linux". В разделе "Управление процессами" написано, что ядро хранит информацию обо всех процессах в двухсвязном списке task list. Вопрос - где он находится?

В памяти ядра, вестимо.

Хочу на него посмотреть.

Посмотри.

Oftentimes, however, it is desirable simply to iterate over all processes in the system. This is easy because the task list is a circular doubly linked list. To obtain the next task in the list, given any valid task, use:

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

list_entry(task->tasks.next, struct task_struct, tasks)

Obtaining the previous works the same way:

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

list_entry(task->tasks.prev, struct task_struct, tasks)

These two routines are provided by the macros next_task(task) and prev_task(task), respectively. Finally, the macro for_each_process(task) is provided, which iterates over the entire task list. On each iteration, task points to the next task in the list:

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

struct task_struct *task;

for_each_process(task) {
    /* this pointlessly prints the name and PID of each task */
    printk("%s[%d]\n", task->comm, task->pid);
}

Note: It can be expensive to iterate over every task in a system with many processes; code should have good reason (and no alternative) before doing so.

http://www.informit.com/articles/article.aspx?p=370047

[andreas90]

Правильно ли я понимаю: Каждый процесса ядра (например показанные по команде top) имеет дескриптор типа struct task_struct ? А пользовательские процессы тоже struct task_struct?
Второй вопрос: зачем вообще нужно thread_info? Ведь в регистре процессора есть указатель на struct task_struct, а мы зачем-то еще один указатель добавляем в thread_info.
В книге, конечно, написано, но я не понимаю.


P.S. Uncle_Theodor объясните еще плиз что такое память ядра.( я погуглил и нашел только то, что память под структуры struct task_struct выделяет slab allocator, но самого определения памяти ядра не нашел)

[Uncle_Theodore]

Правильно ли я понимаю: Каждый процесса ядра (например показанные по команде top) имеет дескриптор типа struct task_struct ? А пользовательские процессы тоже struct task_struct?
Второй вопрос: зачем вообще нужно thread_info? Ведь в регистре процессора есть указатель на struct task_struct, а мы зачем-то еще один указатель добавляем в thread_info.
В книге, конечно, написано, но я не понимаю.


P.S. Uncle_Theodor объясните еще плиз что такое память ядра.( я погуглил и нашел только то, что память под структуры struct task_struct выделяет slab allocator, но самого определения памяти ядра не нашел)

Ёшки... Тут целую лекцию надо читать. В двух словах не объяснишь. Ну ладно, попробую, без претензии на полноту и точность. На пальцах, типа. Товарищи поправят...

Когда ядро грузится, оно спрашивает у БИОСА, куда бы ему загрузиться в физическую память. И обычно получает кусок начиная с физического адреса 0x00100000 или чуть выше. Здесь ядро также хранит свой стак, и всякие task_struct'ы для процессов, которые будут запускаться. Эта область памяти в принципе недоступна для пользовательских программ, и вот примерно почему.
Пользовательские процессы работают с виртуальными адресами памяти. Каждый из них считает, что имеет доступ к незанятой трехгигабайтной области памяти. В действительности, все их обращения к адресам памяти транслируются в физические адреса специальной таблицей (TLB). Так вот, обратиться к памяти ядра через эти таблицы невозможно.

По поводу предыдущих вопросов -- что такое процесс ядра? Ядро грузится и запускает init. Инит становится папой для всех остальных процессов. Никаких процессов ядра не наблюдается... Команда top рассказывает нам о пользовательских процессах, и таки да, каждый из них имеет task_struct в памяти ядра.

По поводу же thread_info -- дело было так. Чтобы не занимать регистра, которых на i386 и так мало, адресом структуры task_struct для (текущего) процесса, решили располагать его (task_struct) в определенном месте, в конце стака, которое ядро держит для процесса -- типа,надо будет -- найдете. Потом решили, что раз структура большого размера, то ее лучше располагать, где места много, динамически. А в конец стака стали писать thread_info, в которой одно поле на task_struct и указывает.

Вот так примерно. Впрочем, это только для i386. Уже для x86_64 все немного сложнее...

А какое это все имеет отношение к Слаке, а?

[andreas90]

1. Я просмотрел содержимое iomem и вот что обнаружил
200000 004919de Kernel code
004919df 00597aef Kernel data
005eb000 006344е7 Kernel bss
Непонятно: почему из всего 3 штуки, ведь образ ядра один и что каждый из них означает (что содержит и зачем нужен)?
2. Вы говорите "Пользовательские процессы работают с виртуальными адресами памяти", это мне неясно. А ядро работает с виртуальной памятью?
3.Вы пишете "Каждый из них считает, что имеет доступ к незанятой трехгигабайтной области памяти." - вообще неясно. Почему 3?
4. Вы пишете "В действительности, все их обращения к адресам памяти транслируются в физические адреса специальной таблицей (TLB)." - непонятно про какие физические адреса идет речь. 004919de - это разве не физический адрес? А где можно посмотреть содержимое таблицы TLB?

Вопрос еще такой: стек ядра и стек процессов - это разные вещи?

[Uncle_Theodore]

1. Я просмотрел содержимое iomem и вот что обнаружил
200000 004919de Kernel code
004919df 00597aef Kernel data
005eb000 006344е7 Kernel bss
Непонятно: почему из всего 3 штуки, ведь образ ядра один и что каждый из них означает (что содержит и зачем нужен)?

Ядро -- это тоже процесс, так что у него есть все те же сегменты, что и у обычного процесса. Код, дата и BSS. А что не так?

2. Вы говорите "Пользовательские процессы работают с виртуальными адресами памяти", это мне неясно. А ядро работает с виртуальной памятью?

Я говорю, пользовательские процессы работают с виртуальными АДРЕСАМИ памяти. Которые не соответствуют физическим. Ядро бегает в ring0, поэтому оно может обращаться к памяти напрямую.

3.Вы пишете "Каждый из них считает, что имеет доступ к незанятой трехгигабайтной области памяти." - вообще неясно. Почему 3?

Так получилось. Из четырех гигов виртуальной памяти процесс может использовать 3.

4. Вы пишете "В действительности, все их обращения к адресам памяти транслируются в физические адреса специальной таблицей (TLB)." - непонятно про какие физические адреса идет речь. 004919de - это разве не физический адрес? А где можно посмотреть содержимое таблицы TLB?

Это не совсем таблица, это кусочек железа. Hardware, то бишь. Наверное, содержимое ее можно посмотреть, разбив ее молотком.

Вопрос еще такой: стек ядра и стек процессов - это разные вещи?

Разные.

В общем, на пальцах, как и следовало ожидать, не вышло. Кратко читайте тут
http://tldp.org/HOWTO/KernelAnalysis-HOWTO-7.html

Более развернуто -- утого же Лова, в Linux Device Drivers и в документации ядра. Сорьки.

[andreas90]

Спасибо, Uncle Theodore, сейчас почитаю. Только мне по этой ссылке непонятно чем code отличается от data. Имеется в ввиду стек (data) , стек данных? И про bss ничего не сказано