-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathreadme
177 lines (118 loc) · 9.43 KB
/
readme
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
-----------------ПЕРВОЕ ЗАДАНИЕ-----------------
К первому заданию относятся файлы uart.c и uart.h
В них есть две функции: init_uart() "--- инициализация последовательного
порта и putc(char c) --- запись в последовательный порт символа c.
В uart.c в комментариях написано, что
какая строчка делает.
В io.c/h реализованны некотрые вспомогательные функции
вывода, потанциально там будет дореализован нормальный
printf пока он реализован с сильно уменьшенной функциональностью,
просто, что бы что-то можно было выводить. Пока
эти файлы читать бесполезно.
Ко второму заданию относится функция init_lpic в
файле interrupt.c и от нее зависимые, опять
постаралась указать в комментариях. На
самом деле кажется, что больше ничего и не относится.
К последниму третьему заданию относится остаток
файла interrupt.c, isr_wrapper.S и немного main.c
isr_wrapper.S --- контроллер прерывания.
В файле interrupt.h из интересного
есть структурка дискриптора прерывания.
В interrupt.c функция make_idt_entry для ее инициализации.
Есть массив idt[256] "--- таблица дискрипторов прерывания
init_interrupt "--- инициализация прерывания.
interrupt_handler "--- собственно обработка прерывания.
Настройка таймера находится в main
-----------------ВТОРОЕ ЗАДАНИЕ-------------------
1) memory_map.c/memory_map.h
void get_memory_map() инициализация массива memory_map, где хранится
адрес куска, размер и тип. Если сломать массив, то можно вызвать функцию еще раз и он
починится.
void print_mempry_map() вывести карту на экран.
2) buddy_allocator.c/buddy_allocator.h
page_descriptor описание одной страницы,
храним иногода список для buddy allocator иногда
информцию в каком slab лежит, для slab аллокатора.
Так же храним, лежит ли этот адрес в списке совбодных кусков 1 если лежит
и order это номер списка в buddy_allocator если лежит.
init_buddy проинициализировать аллокатор, создать список и остальное.
get_page --- отдать страничку
get_page0 отдать страничку и обналить. Отдаем каждый раз 2^k
free_page очищем по адресу 2^k страниц.
2.5) paging.c
void map_init() проинициализировать новую отображалку адресов.
phys_t get_phys_adr(virt_t vad) отобразить этот адрес
void map_adr(virt_t vad, phys_t pad, int big_page) связать этот виртуальный адрес с этим физическим и страничка может
быть большой.
3) SLAB_allocator.c/SLAB_allocator.h
Главный описатель структурки slab
struct slabctl {
uint16_t block_size; - размер блоков
uint16_t alignment; - выравнивание
uint16_t head; - начало списка
uint16_t cnt_ref; - количество выделеных
};
void* allocate_slab(unsigned int size, unsigned int al); выделить новый слаб с этим рамером блока и выравниванием
void* allocate_block(struct slabctl* slab); выделить очередной блок
void free_block(void* addr); освободить блок по адресу.
-------------------------ТРЕТЬЕ ЗАДАНИЕ-----------------------------
Основные файлы, которые относятся к этому заданию:
threads.c/.h, threads_util.S, lock.c/.h, test_thread.c/.h
Так же, были добавлины некоторые блокировки во время выделения памяти
как в слаб, так и в buddy.
threads.c/.h
init_threads() - инициализация пула потоков,
которые у меня храняться. Она склеивает все мои свободные
потоки в список. Я считаю, что у меня может быть только (2^16) потоков.
create_thread(fptr, arg) - принимает функцию и аргумент
запускает в своем потоке, возращает то, что вернула запускаемая
функция.
run_thread(tid) - видимо, эту функцию стоит убрать из
широкого пользования, но когда-то, это был пости единственный способ
с потоками общаться. Это функция переключается с текущего
потока, на поток который был передан.
yield() - сигнал от текущего потока "мне надоело работать, вызовите
кого-то еще". Функция вызывает run_thread для следубщего в
порядке потоку, которому еще актуально что-то делать.
get_current_thread() - возвращает id текущего работающего
потока.
thread_join(pid_t thread, void** retval) поток говорит, кого
он хочет ждать и куда записать значение, которое он вернет.
Предполагается, что поток может ждать только один другой поток.
lock.c/.h
В качестве блокировки выбра ticket lock
spinlock "--- класс по которому блокируемся.
lock(spinlock) "--- захватить этот ресурс.
unlock(spinlock) "--- отдать ресурс.
start_critical_section "--- начать критическую секцию,
по большому счету выключаем прирывания таймера, мы не хотим, что бы
нас вообще в этом месте прерывали, а то все будет очень плохо,
например используется в функции переключения от одного потока к другому.
end_critical_section() "--- закончить критическую секцию.
threads_util.S
start_thread "--- функция, в которую переходим, когда поток начал
выполняться в первый раз, там он уже вызывает настаящую функцию.
switch_threads "--- сменить поток. То есть подменить контекст.
test_thread.c/.h
test_swich_and_arg "--- самый первый тест, просто проверяет, что мы умеем
переключаться и передавать функции аргументы.
test_finish "--- проверяет, что мы выходим из функции, которая закончилась
и больше туда не вернемся.
test_lock "--- проверяет, что как-то работают lockи
test_join "--- проверяет, что мы умеем ждать потоки
test_timer_interrupt "--- а это первый тест, который не самостоятельно
говорит, что он не хочет больше работать, проверяет, что таймер кого-то прерывает
test_slab "--- ему тоже нужно прерывание таймера, проверяет, что я ничего не
сломала в выделение памяти, когда делала выделение потокобезоопасным.
-------------------------ЧЕТВЕРТОЕ ЗАДАНИЕ-----------------------------
К первой части относятся файлы file_system.c, file_system.h, inode.h
В inode.h описывается один узел файловой системы.
file_system.c/h реализована работа непосредственно с файловой системой. Подробнее
в комментариях в коде в h файлах.
Для второй части задания произошли изменения в memory_map.c в функции get_memory_map().
Теперь там же резервируется место для initramfs, если надо. И так же, там происходит
поиск расположения initramfs в функции find_initranfs_mode
Далее парсинг файла и добаление в файловую систему происходт в initramfs.c
Функция initramfs_to_fs().
void* init_ref; --- начало initramfs
void* init_ref_end; --- конец initramfs