-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathREADME.html
More file actions
4323 lines (3660 loc) · 229 KB
/
README.html
File metadata and controls
4323 lines (3660 loc) · 229 KB
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
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<title>Linux kernel v5.1 study log tree</title>
</head>
<body>
<header>
<h2>IAMROOT16 Linux kernel v5.1 study log tree</h2>
</header>
<section>
<p id="param">
We planed studying on week [001 ~ 067] Arm64 Linux kernel boot flow.
so, we reviewed source code line by line,
from <i>arch/arm64/kernel/head.S</i> to <i>init/main.c::start_kernel() → mm/page_alloc.c::page_alloc_init()</i>.
<br>
After week [067 ~ ], we decided to learn each subsystem unit of the Linux kernel,
starting target was the <i>buddy system</i>.
</p>
</section>
<nav id="container"><ol>
<li>
<label for="menu-1-0">week [001 ~ 006] : 리눅스 커널 내부구조 + Arm 리눅스 커널 2판</label>
<input type="checkbox" id="menu-1-0">
<ol>
<li class="file"><a href="">000 (2019-05-18) : OT</a></li>
<li class="file">
<a href="">001 (2019-05-25) : 리눅스 커널 내부구조 - 1장 리눅스 소개, 2장 리눅스 커널 구조 </a>
<textarea readonly rows="112" cols="128">
목차
제0장 운영체제 이야기
1. 운영체제 이야기
2. 운영체제 동작 비유
제1장 리눅스 소개
1. 리눅스의 탄생
2. 유닉스와 리눅스
3. 리눅스의 배포판
4. 리눅스의 장점
5. 쉘(Shell) 사용해보기
제2장 리눅스 커널 구조
1. 리눅스 커널 구조
2. 리눅스 커널 컴파일
실습 문제
제3장 태스트 관리
1. 프로세스와 쓰레드 그리고 태스크
2. 사용자 입장에서 프로세스 구조
3. 프로세스와 쓰레드의 생성과 수행
4. 리눅스의 태스크 모델
5. 태스크 문맥
6. 상태 전이(State Transtion)의 실행 수준 변화
7. 런큐와 스케줄링
8. 문맥 교환
9. 태스크와 시그널
실습 문제
제4장 메모리 관리
1. 메모리 관리 기법과 가상 메모리
2. 물리 메모리 관리 자료 구조
2-1 node
2-2 zone
2-3 page frame
3. Buddy와 Slab
3-1 버디 할당자(Buddy Allocator)
3-2 Lazy Buddy
3-3 슬랩 할당자(Slab Allocator)
4. 가상 메모리 관리 기법
5. 가상 메모리와 물리 메모리의 연결 및 변환
6. 커널 주소 공간
7. Slub, Slob
실습 문제
제5장 파일시스템과 가상 파일시스템
1. 파일 시스템 일반
2. 디스크 구조와 블록 관리 기법
3. FAT 파일시스템
4. inode 구조
5. Ext2 파일시스템
6. Ext3 파일시스템과 Ext4 파일시스템
7. 가상 파일시스템(Virtual File System)
8. 태스크 구조와 VFS 객체
9. 파일시스템 제어 흐름 분석
실습 문제
제6장 인터럽트와 트랩 그리고 시스템 호출
1. 인터럽트 처리 과정
2. 시스템 호출 처리 과정
3. 새로운 시스템 호출 구현
4. 시스템 호출 구현 확장
4-1 커널 정보 출력
4-2 인자 전달
4-3 구조체를 사용한 인자 전달
실습 문제
제7장 리눅스 모듈 프로그래밍
1. 마이크로 커널
2. 모듈 프로그래밍 무작정 따라하기
3. 시스템 호출 hooking
4. 시스템 호출 hooking 모듈 확장
실습 문제
제8장 디바이스 드라이버
1. 디바이스 드라이버 일반
2. 문자 디바이스 드라이버 구조
3. 블록 디바이스 드라이버 구조
실습 문제
제9장 네트워킹
1. 계층 구조
2. 주요 커널 내부 구조
3. 리눅스에서 통신 프로토콜의 제어 흐름
실습 문제
제10장 운영체제 관련 실습
1. 쉘(Shell)
2. 스케줄러와 시뮬레이팅 환경
3. 버디 할당자와 시뮬레이팅 환경
4. FAT 파일시스템과 디스크 에뮬레이팅 환경
4-1 파일 시스템 마운트
4-2 파일의 생성 및 쓰기
4-3 파일의 탐색 및 읽기
4-4 파일의 삭제
부록A 리눅스와 가상화 그리고 XEN
1. 가상화 기법의 이해
2. 가상화 기술
3. Xen
3-1 전가상화 기술을 이용한 리눅스 설치
3-2 전가상화 기술을 이용한 윈도즈 설치
부록B MTD와 YAFFS
1. 플래시 메모리의 이해
2. MTD
3. YAFFS
부록C Map of the Linux
</textarea>
</li>
<li class="file"><a href="">002 (2019-06-01) : 리눅스 커널 내부구조 - 3장 태스크 관리, 4장 메모리 관리 </a></li>
<li class="file">
<a href="">003 (2019-06-08) : 리눅스 커널 내부구조 - 5장 파일시스템과 가상 파일시스템</a>
<textarea readonly rows="32" cols="128">
(1) 파일시스템 질문: 136p FAT 파일 중간데이터를 읽을때,
처음 블록부터 읽을 필요가없다고 나와있는데, 어떻게?
- FAT파일 시스템도 "인덱스 블록 기법" 처럼 블록 위치를 테이블로 관리함.
- FAT는 클러스터 단위로 파일의 데이터를 관리하여,
"클러스터 테이블" 이 "인덱스 블록" 과 같은 역할을 함.
- 즉, 파일 데이터는 순서대로 클러스터 테이블로 관리하고,
디렉토리 엔트리에서 파일의 크기를 알수있으므로 중간 데이터의 위치를 얻을 수 있음.
(2) FAT vs ext 동작방식, 슈퍼블록 구성 방식 차이
- FAT의 슈퍼블록은 하나로 관리함. FAT 할당 기법으로 하나의 블록을 전체 블록으로 하여 관리함.
- ext는 복수 블록 그룹 마다 관리함.
(3) 5장 파일시스템 : 140p i-links-count 가 사용되는 예시?
- "hard link"하고 있는 다른 파일이 삭제 되어도, 원본 파일은 삭제되지 않음.
- 다른 파일이 "hard link"할 때마다 "i_links_count"가 증가함.
- 이 값이 '0'이 되면 삭제됨.
- https://www.nongnu.org/ext2-doc/ext2.html#i-links-count
(4) 파일시스템 질문 (2조 seo) : Ext2 파일시스템에서 디렉토리에 속해 있는 파일 정보 얻는 방법?
145p 그림5.13 설명에서, "disk block 20" 에 파일 정보가 있다는 것을 어떻게 알수 있을까?
"disk block 20"의 자료구조는 어떻게 구성 되어있을까? (144p 마지막 단락 3,4번째 설명 참조)
- i_mode 를 읽어서, 파일 속성이 디렉토리 이므로,
이 데이터의 시작 블록 20 은 디렉토리 엔트리 자료구조가 있음을 알 수 있음.
</textarea>
</li>
<li class="file">
<a href="">004 (2019-06-15) : 리눅스 커널 내부구조 - 5장 파일시스템과 가상 파일시스템, 6장 인터럽트와 트랩 그리고 시스템 호출</a>
<textarea readonly rows="32" cols="150">
(1) 5장 파일시스템 질문(1조 이파란) : 156p sys_open() vs sys_read() 의 기능적 차이점
- Functions like open() , printf() , scanf() , read() are library function
implemented on top of their sys_* counterparts.
- so they can be used for any Application development.
- On the other hand sys_open, sys_close, sys_read etc are implemented as-part-of-system commonly known as "kernel".
- https://stackoverflow.com/questions/1628540/are-programs-like-sys-open-sys-read-et-al-examples-of-system-level-progra
(2) 5장 파일시스템 질문(4조, 노영진) : p151.line4, p152.line6를 보면
"파일 이름을 보고 파일을 관리하는 파일시스템이 무엇인지 판단한다"고 나와있는데,
파일 이름을 가지고 파일시스템을 어떻게 알아내는지?
- where-are-filenames-stored-on-a-filesystem? See Directory Structure.
- Unix directories are lists of association structures, each of which contains one filename and one inode number.
- So the name of the file is stored within the directories' information structure.
- https://unix.stackexchange.com/questions/117325/where-are-filenames-stored-on-a-filesystem
(3) 6장 인터럽트와 트랩 그리고 시스템 호출 (1조 이파란) : 171p 트랩을 세가지로 구분하는 이유
- fault trap abort의 구분은 핸들러가 수행된 이후 Return Address(eip)하고 연관됨.
</textarea>
</li>
<li class="file">
<a href="">005 (2019-06-22) : Arm 리눅스 커널 2판 - 1장 ARMv8 아키텍처 1</a>
<p>
<textarea readonly rows="56" cols="128">
숙지하고 있습니까? 당신? Arm 64 커널을 공부한다?
1.1 ARMv8 소개 4
1.1.1 익셉션 모델 5
1.1.2 익셉션 레벨 변경 6
1.1.3 실행 상태 7
1.1.4 실행 상태 변경 7
1.2 ARMv8 레지스터 8
1.2.1 프로세서 상태 레지스터(PSTATE) 9
1.2.2 AArch64 특수 목적 레지스터 10
1.2.3 시스템 레지스터 12
1.2.4 ABI의 레지스터 사용 규칙 12
1.3 AArch64 익셉션 핸들링 13
1.3.1 익셉션 타입 14
1.3.2 동기 및 비동기 익셉션 15
1.3.3 익셉션 핸들링 16
1.3.4 익셉션에 의해 변경되는 실행 상태와 익셉션 레벨 17
1.3.5 AArch64 익셉션 벡터 테이블 19
1.3.6 인터럽트 핸들링 20
1.3.7 GIC 표준 인터럽트 컨트롤러 21
1.4 캐시 21
1.4.1 캐시 구조 22
1.4.2 캐시 컨트롤러 24
1.4.3 캐시 정책 24
1.4.4 캐시 일관성의 두 가지 관점 25
1.4.5 캐시 관리 27
1.4.6 캐시 탐색 27
1.5 MMU 28
1.5.1 가상 주소를 물리 주소로 변환 29
1.5.2 AArch64의 테이블 디스크립터 종류 30
1.5.3 커널과 애플리케이션의 가상 주소 공간 분리 32
1.5.4 변환 테이블의 cacheable과 shareable 속성 33
1.5.5 디스크립터 메모리 속성 34
1.5.6 시큐리티와 MMU 36
1.5.7 컨텍스트 스위칭 36
1.6 메모리 오더링 37
1.6.1 메모리 타입 39
1.6.2 배리어 41
1.6.3 메모리 속성 42
1.7 멀티코어 프로세서 44
1.7.1 멀티프로세싱 시스템 44
1.7.2 캐시 일관성 47
1.7.3 클러스터 내의 멀티코어 캐시 일관성 48
1.7.4 버스 프로토콜과 캐시 일관성 인터커넥트 51
1.8 전력 관리 52
1.8.1 유휴 상태 관리 52
1.8.2 소비전류 관련 인스트럭션 54
1.8.3 PSCI 54
</textarea>
</p>
<p>
<textarea readonly rows="32" cols="128">
(1) Arm 리눅스 커널 1장 (1조 이파란)
: 5p 하이퍼바이저와 보안모니터의 주체 (하드웨어적? 소프트웨어적으로? 펌웨어?)
- hypervisor mode desciptions : 2140 PAGE
- https://static.docs.arm.com/ddi0487/db/DDI0487D_b_armv8_arm.pdf
(2) Arm 리눅스 커널 1장 (1조 최지영)
: 18p 익셉션 모드가 어떤 상황일 때 하이퍼 바이저로 전환되는지?
- 호스트가 자신을 지탱하는 하이퍼 바이저에게 서비스를 요청하면 바뀜.
(3) ARM 리눅스 커널 1장 (4조 박진우)
: AArch64 는 V7A와 같이 CP15를 통한 Coprocessor을 지원하지 않음.
- 대표적인 ARMv8A의 SoC칩들은 GPU 나
전원/외부단순 인터페이스용으로 Cortex-M Core 을 가지고 있는 경우가 있음.
(4) ARM 리눅스 커널 1장(3조 김태형)
: 익셉션 벡터 테이블 옵셋이 기존 ARM 아키텍쳐에서는 4Byte이었는데 128Byte로 바꾼 이유?
- aarch64 의 Exception Table 사용 예시 (리눅스 메일링 리스트 인용)
- https://lore.kernel.org/patchwork/patch/312340/
- Aarch64에서는 exception table에 명령어를 넣고
(aarch32의 어셈블리라면 2배로 더 많이 들어감)
- http://recipes.egloos.com/5035801
- 차후 Exception table을 다루는 단원/코드 분석에서 보자!
(5) ARM 리눅스 커널 1장 (3조 김태형)
: 31페이지의 주소변환 테이블의 구성 이미지가 있는데 블록 디스크립터가 어떻게 맵핑이 되는지?
- 매핑한 페이지 디스크립터
</textarea>
</p>
</li>
<li class="file">
<a href="">006 (2019-06-29) : Arm 리눅스 커널 2판 - 1.5 MMU</a>
<textarea readonly rows="32" cols="160">
(1) AArch64 디스크립터 타입 중 테이블 엔트리 포맷?
- http://jake.dothome.co.kr/pt64/
(2) ARM 리눅스 커널 1장 (2조 최자은) :
35p [OS의 변환 테이블 디스크립터 사용]
AF를 설정함으로써 1) 늦은 할당이 가능하고
2) 스왑아웃할 때는 사용 중인 페이지를 스왑아웃할 가능성이 낮아진다?
- https://static.docs.arm.com/100940/0100/armv8_a_address%20translation_100940_0100_en.pdf
page 24페이지에 관련내용이 있는것 같음.
(3) 1조 1.6 메모리 오더링?
- http://jake.dothome.co.kr/barriers/
(4) 4조 질문 : 파워다운모드와 휴먼 모드의 차이점?
- https://developer.arm.com/documentation/100737/0100/Power-management/Wakeup-from-sleep-mode/Wakeup-Interrupt-Controller--WIC-
</textarea>
</li>
</ol>
</li>
<li>
<label for="menu-1-1">week [007 ~ 018] : arch/arm64/kernel/head.S</label>
<input type="checkbox" id="menu-1-1">
<ol>
<li class="file">
<a href="">007 (2019-07-06) : arch/arm64/kernel/head.S</a>
<textarea readonly rows="32" cols="128">
* 항상 업데이트 되는 Arm v8 매뉴얼 링크
- https://kib.kiev.ua/x86docs/ARM/
* GNU 어셈블러 매뉴얼
- https://sourceware.org/binutils/docs/as/
- https://en.wikipedia.org/wiki/GNU_Assembler
- http://tigcc.ticalc.org/doc/gnuasm.html
* 부트업 헤드 설정
- https://elixir.bootlin.com/linux/latest/source/Documentation/arm64/booting.txt
* Branch 명령어 종류와 차이점
- http://trace32.com/wiki/index.php/B,_BL,_BX_and_BLX
- https://modexp.wordpress.com/2018/10/30/arm64-assembly/
* __inval_dcache_area (preserve_boot_args의 tail call) 관련 위치
ENTRY(__inval_dcache_area)
- arch/arm64/mm/cache.S
extern void __inval_dcache_area(void *addr, size_t len);
- arch/arm64/include/asm/cacheflush.h : 78
</textarea>
</li>
<li class="file">
<a href="">008 (2019-07-13) : arch/arm64/kernel/head.S</a>
<textarea readonly rows="64" cols="128">
ENTRY(el2_setup)
* Arm 베리어 관련 정리 내용 공유
http://forum.falinux.com/zbxe/index.php?document_srl=534002&mid=Kernel_API
* SPsel
- https://developer.arm.com/docs/100878/latest/processor-state
* subsection
- https://sourceware.org/binutils/docs/as/Sub_002dSections.html#Sub_002dSections
* SCTLR
- https://developer.arm.com/docs/100878/latest/the-system-control-register
* ARM에서 immediate를 encoding 하는 방식에 관한 설명. armv8에서도 동일하게 적용되는지 확인 필요.
- https://alisdair.mcdiarmid.org/arm-immediate-value-encoding/
__PHYS_OFFSET == 0x82000
* adr 내용입니다
- http://forum.falinux.com/zbxe/index.php?document_srl=627913&mid=lecture_tip
* arch/arm64/mm/cache.S::__inval_dcache_area ()
132 * __inval_dcache_area(kaddr, size)
133 *
134 * Ensure that any D-cache lines for the interval [kaddr, kaddr+size)
135 * are invalidated. Any partial lines at the ends of the interval are
136 * also cleaned to PoC to prevent data loss.
프로시저 전체 주석과 라인별 주석에 설명이 나와 있네요.
kaddr부터 size크기만큼 dcache를 invalidate(clean은 더티 캐시를 다음 레벨의 캐시/메모리에 써주는 것,
invalidate는 캐시라인을 무효화시키는 것)하는 함수입니다.
시작 주소, 끝 주소 써주면 알아서 동작하면 좋으련만 아키텍처를 그렇게 설계할 수는 없죠.
몇 가지 캐시 오퍼레이션이 있는데, armv8에서 최대한 친절하게 종류별로 옵션을 달아줬으니
필요한 오퍼레이션 선택해서 짜면 저렇게 나오겠죠.
캐시라인 단위로 반복문 돌면서 invalidate 시키는데(dc ivac),
지우고 싶은 메모리가 캐시라인에 맞게 딱 떨어지지 않고 걸쳐 있을 때를 고려해 준 거죠.
시작 주소랑 끝주소가 캐시라인에 걸쳐 있는지 딱 들어맞는지(cache line aligned?)
비교해서(tst 명령과 b.eq 조합) clean & invalidate(dc civac) 시켜준 것입니다.
cache hierarchy나 용어는 아키텍처 문서 참고하시면 될 것이고요,
instruction은 TRM(technical reference manual) 참고하시면 될 것 같습니다.
참고: http://events17.linuxfoundation.org/sites/events/files/slides/slides_17.pdf
- http://www.iamroot.org/xe/index.php?document_srl=206739&mid=Programming#2
* CTR (Cache Type Register)
- https://developer.arm.com/docs/ddi0433/a/system-control/register-descriptions/cache-type-register
</textarea>
</li>
<li class="file">
<a href="">009 (2019-07-20) : arch/arm64/kernel/head.S</a>
<textarea readonly rows="24" cols="128">
* MT_NORMAL
- http://jake.dothome.co.kr/map64/
* .inst expressions
- Inserts the expressions into the output as if they were instructions, rather than data.
- https://sourceware.org/binutils/docs/as/AArch64-Directives.html#AArch64-Directives
* sys_reg() 관련
- http://jake.dothome.co.kr/cpucaps64/
* MMFR2 레지스터
- http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0363e/Bgbfhfjc.html
</textarea>
</li>
<li class="file">
<a href="">010 (2019-07-27) : arch/arm64/kernel/head.S</a>
<textarea readonly rows="16" cols="128">
* arch/arm64/kernel/head.S .macro map_memory()
* .macro populate_entries에 나오는 ".Lpe\@" 의 \@에 관련
https://sourceware.org/binutils/docs/as/Macro.html#Macro
\@
as maintains a counter of how many macros it has executed in this pseudo-variable;
you can copy that number to your output with ‘\@’, but only within a macro definition.
</textarea>
</li>
<li class="file">
<a href="">011 (2019-08-03) : arch/arm64/kernel/head.S</a>
<textarea readonly rows="32" cols="150">
compute_indices
- populate_entries
* Check ID_AA64DFR0_EL1 PMUVer
- PMU : Performance Monitoring Unit, or the PMU, is found in all high end processors these days.
The PMU is basically hardware built inside a processor to measure it's performance parameters.
We can measure parameters like instruction cycles, cache hits, cache misses, branch misses
and many others depending on the support i.e. hardware provide by the processor.
* MT_XXXX 관련
- http://jake.dothome.co.kr/map64/
* IPA 관련
- https://developer.arm.com/architectures/learn-the-architecture/armv8-a-virtualization/stage-2-translation
* Arm64 Assembly cheet sheet 간소화
- https://courses.cs.washington.edu/courses/cse469/18wi/Materials/arm64.pdf
</textarea>
</li>
<li class="file">
<a href="">012 (2019-08-10) : arch/arm64/kernel/head.S</a>
<textarea readonly rows="165" cols="178">
* Cache
-> Kernel code(Driver Code 를 제외한 Kernel Core code) 를 복잡하게 만드는 주요한 원인 중 하나
* Kernel code =
Kernel core code
+ Subsystem code (Architecture 마다 Kernel 이 동작하도록 각 system 별로 구현한 것)
+ Driver code
* Kernel core code = Memory management + Task management + Lock, ...
* C++, Java, C# 이 Kernel에서 쓰이지 않는 이유?
- OOP 는 일단 객체 생성을 위해서 Memory 할당이 필요함.
- Kernel 단에서 객체 생성을 위한 Memory 할당 자체가 어려움.
- Kernel 이 Memory management 역할을 하기 때문임.
* Cache Tree : Low <-> High level 단에서의 속도 차이를 해소하기 위한 장치
- L1, L2 Cache 는 DRAM 의 느린 동작을 보완하여 System Performance 증가하기 위해 사용함.
- L1 Cache 가 필요 없으려면? -> CPU Clock 속도와 Memory R/W 속도가 일치해서 Zero Latency 가 유지된다면 가능함.
- {(CPU1, L1), (CPU2, L1)}-(L2)-<Memory>
- L1 Cache -> SRAM 으로 제작됨. 2 Clock 정도의 속도로 L1 Cache 에 접근 가능.
- 과거 10MHz CPU 에 SRAM, DRAM 을 달았을 때는, 속도 차이가 크게 안났음. But, 현재와 같은 GHz CPU 는 속도 차이가 100배 이상 남.
* Lock 이란?
여러 개의 Task 가 진행되고 있을 때, Masking 을 통해 순서를 지정해주는 것. (대기하는 Task 는 Spin 상태에 있다고 표현)
Lock 의 Masking 과정은 굉장히 느림. (특히, LDR, STR 명령어의 경우 시간이 굉장히 오래 걸림.)
- {(CPU1, L1), (CPU2, L1), (CPU3, L1)}-(L2)-<Memory>
각 CPU - L1 - L2 - Memory 가 수행할 때 공유하는 태스크나 값에 대한 정보를 서로 공유해야함.
해당 공유 작업 자체도 Clock 이 굉장히 많이 소요되게 됨. (CPU Core 가 병렬적으로 늘어났기 때문임.)
- Clock 속도는 5GHz 의 벽을 넘지 못하고(실리콘적인 병목 현상), Core 를 병렬적으로 늘리기 시작함.
- CPU 스케쥴링: CPU 가 한 Task(Process) 의 명령어를 수행하다가, 다른 Task 의 명령어 수행으로 전환되는 것.
시분할 단위로 스케쥴링이 이루어지기 때문에, 마치 한 시간대에 여러 Task 가 수행되는 것처럼 보임.
- Thread : 각 Process 간의 Scheduling 단위
(과거에는 Scheduling 단위는 Process 였으나, Process 하부의 Thread 단위로 변경되었으며, 현재는 Schedule Entity 단위로 수행)
Kernel Space // User Space
- User Space 에서 3개의 Process 가 Process1(Thread1, Thread1-1, Thread1-2), Process2(Thread1), Process3(Thread1)
- 총 5개의 Thread (각 Thread 는 Task Struct 로 관리 함)
- 각 20% 씩 Thread 가 수행됨 (총 100%)
- 여기서 그러면, Kernel 은 언제돌까? 어느 CPU 에서 돌까?
5개의 Task 가 Scheduling 되는 도중, Interrupt 가 발생했을 때 (EL0 -> EL1 변경), Kernel 실행된 후 다시 복귀함.
- Kernel Space 에는 Kernel 용 Thread 가 존재함. (Interrupt 해결을 위해 존재하며, User Thread 처럼 항상 열심히 돌고있지는 않음.)
- 대부분의 CPU 수행 시간은 User Thread 가 차지함.
- 네트워크나 SSD 와 같은 고성능 장치들에 의한 Interrupt 가 어마무시하게 들어오면,
EL0 -> EL1 -> EL0 하는 Interrupt 처리가 많아져서 User Thread 의 다른 태스크를 처리하지 못할 정도로
CPU 할당이 길어져 throughput이 낮아짐. 즉, Interrup overhead 가 발생함.
- task가 잠시 중단하고 interrupt vector로 이동하여 irq 등을 처리하는 것을 전반부 처리라고 함.
- 전반부 처리에서ㄴ,ㄴ 인터럽트가 빠르게 완료되는 동작이나, 당장 처리해야 하는 것만 처리함.
- 고속의 대량 네트워크 패킷도, Receive 하는 동작만 처리한 뒤, 해당 패킷에 대한 처리 등을 후반부 처리에게 전달함.
ex) Kernel 단에 SKB (Socket Buffer) 가 존재하고, User 단에서는 TCP/IP 가 있으며, Web 과 연결되어 있음.
이 때, 네트워크 Interrupt 가 다량 발생시, Overhead 발생으로 인해 Kernel 단에서 Overhead 해결이 안됨.
-> 해결 : Kernel 단의 역할을 User Space 쪽으로 이동 시켜준다! (User Space 에서 고속으로 네트워크 Interrupt 처리)
Kernel 도움 없이 User 단에서 TCP/IP, Interrupt 처리 (10G 속도의 Interrupt 해결 위함.)
File Server 등에서 많이 사용. ex) Youtube, Netflix (고속 네트워크 + 고용량/고속 Disk)
10G Network - XDP -> 필요한 부분만 Kernel 단의 SKB 로 넘기고, 나머지는 User Space 에서 처리함! (User Application 을 활용할 수 있음!)
- 잠깐, XDP 를 통해 Kernel 단에서 처리할 것과 User 단에서 처리할 것을 나누는 Filter 역할을 해줄 수 있을 뿐임.
Kernel 단에서 처리 속도가 빨라지는 방법은 아님.
Kernel 단에서 처리 : XDP, User 단에서 처리 : DPDK (스위치 등의 개발 업체에서 사용?)
과거 : Kernel Space Driver 속도 > User Space Driver 속도 (고속의 네트워크 개발 이전)
현재 : Kernel Space Driver 속도 < User Space Driver 속도 (고속의 네트워크 등장 이후)
-> Scheduling 을 안하는게 더 처리 속도가 빨라짐?
-> Kernel 단의 처리 속도를 빠르게 할려고 하는 노력이 이루어짐.
* cache <-> DRAM
- DRAM 의 속도가 L1, L2 캐시 만큼 빨라지기 전까지는, L1, L2 캐시는 어쩔 수 없이 쓸 수밖에 없음.
- 명령 파이프(각 Stage 별로 저장하는 공간이 자리하기 때문.)
- 예측 분기(Branch Predict)를 위한 캐시(i.e. BL 의 경우 Return 위치를 미리 예측/저장)
- Interrupt Vector : DRAM 에 vector Table 있음.
- TLB Cache (Page Table Cache) : Main TLB, Micro TLB | L1 TLB, L2 TLB 등으로 나눠짐.
- Load, Store Buffer (4단계의 Store 작업을 위해 Writing Buffer 를 둠.) SRAM 으로 구성함.
* ARM CPU 파이프라인 <초기> : 4단계 (Fetch, Decode, Execute, Store)
- <현재> Stage 수가 훨씬 많아짐. (신축성 있게) 그리고 Instruction 마다 Stage 수가 달라짐.
* ARM <초기> : 1 Clock 당 Instruction 1개 처리
- <현재>의 고성능 Architecture : 1 Clock 당 Instruction 2개 이상 처리
- (SIMD 와 결합시 5개 이상 가능)
- Multi Issue : 정수 연산 처리 기준으로 몇 개의 연산을 동시에 처리 가능한가?
* Architecture 별로 Cache 가 다양하게 많이 도입되었기 때문에, 관련 Code 들이 굉장히 많이 늘어남.
ex) 명령 캐시, 데이터 캐시, TLB 캐시와 관련된 ISA 가 많이 추가 되었음.
해당 캐시들을 조작(Cache Operation)하는 것과 관련된 ISA 가 추가 되었음.
Cache Operation : i.e. Cache 를 비워라!
i.e. Invalidate (Cache 비움), Clean(DRAM 에 저장된 Cache Dirty data 저장?)
Flush : Invalidate or Clean (ARM 에서는 쓰이지 않음)
1) Invalidate
2) Clean
3) Invalidate & Clean
-> Background 에서 동작함.
-> A code --> B code 로 runtime 시, Clean 명령 시 Cache 가 비워질 때까지 기다리는 경우가 있음.
이 경우, Barrier (Cache 가 비워질 때까지 Instruction 대기함.)를 사용
-> Barrier 는 대기시간이 김 (Cost 가 큼; 시간 낭비가 큼.)
* O.O.O (Out Of Order) - weak
- 최근 Architecture 가 채택.
- Program 명령어 들의 순서가 바뀌어 수행될 수 있다는 가능성 있음.
- 의존성이 있는 구문의 명령어들은 순서를 안 바꾸기로 함.
그런데, 관련이 없어보이는데 실제로는 의존성이 있는 구문인 경우가 있음!
- 이럴 때, Barrier 를 '잘' 사용해야함. (User mode 에서도 Barrier 를 사용할 준비를 함.)
고속의 처리가 필요한 부분 : Cost 가 낮은 Barrier 를 사용
명령어 순서 보존이 훨씬 중요한 부분 : Cost 가 높은 Barrier 사용
- 최근의 SMP CPU -> DSB sy , DSB ish (inner share) : CPU core 들 끼리의 Barrier 동기화 시킴.
(CPU core 가 여러 개니깐, 다른 core 들까지 Barrier 상태를 동기화 시키는 것.)
DSB nsh | (outer share) : CPU core 들 이외의 GPU core 들까지 Barrier 를 동기화 시키는 경우
Barrier cost 를 명시해야만 Barrier 적용이 명확하게 잘됨?
- 명령어 순서도 바뀔 수 있고, Memory 에 저장 순서도 바뀔 수 있음
명령어 순서 보존 : ISB
Memory 순서 보존 : DMB
이외 DSB (Cost 가 가장 높음)
* I.O.O (In of Order) - strong
- 단방향 Barrier <-> 양방향 Barrier
- ldar, stlr (ARMv8)은 이전의 Barrier 에 비해서 속도가 어마무시하게 빠름.
* Barrier Option
- Shareable?
inner share : CPU core
outer share : CPU core <-> GPU core
option 에 따라서 Read 만 Barrier 칠수도, Write 만 Barrier 칠수도 있음.
Architecture 단위의 Barrier 내용임.
이와는 별개로 Compiler 단위에서 Barrier 개념도 있음.
- ISB : 명령 파이프를 비우고, PoU 코드를 넣고, 다시 한번 ISB를 침으로써 Self Modification / Page Table Modification 에 대응, 이후 DSB 를 사용
- DMB : Half Barrier, SMP Barrier, ... , etc
- SMP CPU 체계에서 CPU core 들 간에 간섭이 일어나는 code 들은 Architecture 단에서 DMB 를 사용하더라도 순서가 바뀔 수 있음.
ex) A Core [flag = 1] --- B Core [if(flag) loop, printf(Data) -> 1]
A core [Data = 10] --- B core [printf(Data) -> 0 ???? 10 아니고??]
Uni-Process system 에서는 상관이 없는데,
SMP (Multi-Process system) 에서는 뮤텍스 락/언락을 걸지 않는 이상 이러한 문제가 발생할 수 있음.
락/언락 작업을 할 때마다 데드락 걸릴 위험성이 크며, 속도도 저하됨
뮤텍스 대신 DMB 를 쓸 수 있음. (User level : 뮤텍스, Kernel level : DMB)
Barrier, PoC, PoU 등의 개념이 ARM Cache system 을 이해하기 위해 필수적임.
* Cache coherency
- CPU 와 Device 는 DRAM 을 통해 Data 를 주고받음.
- CPU 의 Cache 에 Dirty flag 가 설정되어 있고, DRAM 과 내용이 다르다면, Device 의 Data 전송이 실패함
- 최근의 Architecture : ACP 를 통해 Cache Coherency 처리함 (HW 단에서 Cache Coherency)
- ACP 를 사용하지 못하는 Device 들 : Flush 를 통해 Data 깨짐을 방지함.
- MT_DEVICE_nGnRnE : non Gathering (모아서 처리하지 마시오), non Reordering, non Early Byte
_non ~ : 속도가 느려지는 작업들.
_DEVICE -> NORMAL 과 다르게 Prefetch 기능이 없음.
- Cache, Mapping : Architecture 을 정확히 알아야 제대로 이해 가능.
- Poc, PoU 와 같은 작업 들은, HW 가 해결해줄 수 없는 부분으로, SW 적으로 해결해야함.
PoC : Point of Coherency (== Location of Coherency ; LoC)
다음 캐시와 일관성을 가져야 하는 단계의 캐시
Device -- DMA -- DRAM -- Cache(x) -- Cache (y) -- CPU
=> Cache(x) 와 Cache(y) 에 Clean & Invalidate 과정이 필요.
언제 Clean 을 하고, 언제 Invalidate 를 사용함?
Write 동작을 하는 DMA 를 할 때는 Invalidate 를 함. (Invalidate 속도 >> Clean 속도)
PoU : Point of Unification (통합 캐시 레벨)
ARM 의 경우 L2 캐시 부터 I-Cache, D-Cachea 가 나뉘지 않음
이런 L2 캐시를 PoU 라고 함.
Kernel code 중에서 성능 향상을 위해 미리 Branch 를 어느쪽으로 할지 결정할 수 있는 기능이 있음.
if 문 사용 시 (어셈블리에서 b.ne) 괜히 CPU Clock 을 사용하지 않게, 어차피 Branch 할 부분으로 Jump 하게 코드를 실시간으로 변경함.
(User Level 단에서는 Java code가 유사한 기능이 있음. 실행 중에 code가 실시간으로 변경됨.)
LDR 명령어 -> I-Cache 에는 이전 명령어 저장되어 있고, D-Cache(L1) 와 DRAM 에는 해당 내용이 저장됨.
1. Self modification code 가 있을 때는 flush 를 통해 명령어를 비워주는 행위가 꼭 필요. (PoU 방식의 Barrier)
2. Page Table(Mapping entry) 이 바뀔 때도, Flush 를 통해서 기존 Mapping 들을 비워줘야함.
바뀐 내용이 D-Cache 나 DRAM 에만 반영되고 I-Cache 에는 반영이 안 되어있음
</textarea>
</li>
<li class="file">
<a href="">013 (2019-08-24) : arch/arm64/kernel/head.S</a>
<textarea readonly rows="4" cols="128">
* tst x23, ~(MIN_KIMG_ALIGN - 1) 에 대한 커밋 내용
- http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/413173.html
</textarea>
</li>
<li class="file">
<a href="">014 (2019-08-31) : arch/arm64/kernel/head.S</a>
<textarea readonly rows="32" cols="128">
* Low level Exception
- https://s-matyukevich.github.io/raspberry-pi-os/docs/lesson03/linux/low_level-exception_handling.html
* SSBD 이슈
- https://lwn.net/Articles/755211/
* GICC_PMR
- http://jake.dothome.co.kr/ic/
* arch/arm64/include/asm/ptrace.h
159 /*
160 * This struct defines the way the registers are stored on the stack during an
161 * exception. Note that sizeof(struct pt_regs) has to be a multiple of 16 (for
162 * stack alignment). struct user_pt_regs must form a prefix of struct pt_regs.
163 */
164 struct pt_reg
</textarea>
</li>
<li class="file">
<a href="">015 (2019-09-21) : arch/arm64/kernel/head.S</a>
<textarea readonly rows="64" cols="150">
* static unsigned int array[10] = { [0] = 5, [1] = 5, [2] = 5, [3] = 5, [4] = 5, [5] = 5, [6] = 5, [7] = 5, [8] = 5, [9] = 5};
* static unsigned int array[10] = { [ 0 ... 9 ] = 5 };
* _Bool lowercase_eh(char c)
{
switch(c) case 'a' ... 'z': return 1;
return 0;
}
- https://stackoverflow.com/questions/56598905/three-dots-operator-for-initializing-an-array
* asm volatile
- https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
asm asm-qualifiers ( AssemblerTemplate
: OutputOperands
[ : InputOperands
[ : Clobbers ] ])
asm asm-qualifiers ( AssemblerTemplate
: OutputOperands
: InputOperands
: Clobbers
: GotoLabels)
* debug_object_early_init() 함수는 .config 파일 내에 CONFIG_DEBUG_OBJECTS 가
정의되어 있지 않으면 빈함수이고
정의되어 있으면 lib/debugobjects.c 파일에 기술되어 있는 함수가 사용된다.
이 함수는 obj_hash 구조체 배열과 obj_static_pool 구조체 배열을 초기화 한다.
- http://m.blog.daum.net/english_100/86?np_nil_b=1
- http://jake.dothome.co.kr/debug_objects_early_init/
* ((void)(((typeof(p) space )p) == p)) 관련 참고하세요.
- https://stackoverflow.com/questions/34288844/what-does-casting-to-void-really-do
* IDR (Integer ID 관리)
- http://jake.dothome.co.kr/idr/
* local_irq_disable()
- http://jake.dothome.co.kr/local_irq_disable/
</textarea>
</li>
<li class="file">
<a href="">016 (2019-09-28) : arch/arm64/kernel/head.S</a>
<textarea readonly rows="64" cols="128">
* DEFINE_PER_CPU_SECTION 관련
- https://0xax.gitbooks.io/linux-insides/content/Concepts/linux-cpu-1.html
* __verify_pcpu_ptr 관련
- http://egloos.zum.com/studyfoss/v/5375570
* tpidr_el1 관련
- https://developer.arm.com/docs/ddi0595/latest/aarch64-system-registers/tpidr_el1
* inline assembly
- http://jake.dothome.co.kr/inline-assembly/
* RELOC_HIDE 매크로
Linux: 2.6.35RELOC_HIDE() 매크로는 컴파일러의 최적화/오동작(?)을 방지하려는 목적으로 만들어짐.
gcc의 경우 다음과 같이 정의되어 있다.
include/linux/compiler-gcc.h:#define RELOC_HIDE(ptr, off)
- http://egloos.zum.com/studyfoss/v/5374731
* preempt_count() 는 현재 스레드 정보(thread_info 구조체)에서 preempt_count를 리턴함.
preempt_count 값은 preempt_enable() 호출 시 감소되며 preempt_disable() 호출 시 증가됨.
preempt_count 값이 0인 경우 preemption이 가능한 상태가 됨.
- http://jake.dothome.co.kr/tag/function/
* preemption disabled 관련
현대의 OS는 대부분 preemptive multitasking을 지원함.
preemption이란, 어느 thread가 수행 중인데,
느닷없이 그 thread가 동작을 멈추고 다른 thread가 수행되는 것을 가리킴.
preempt_disable은 이러한 preemption을 막기 위해서 사용함.
- http://egloos.zum.com/nimhaplz/v/5683475
* READ_ONCE WRITE_ONCE 관련
- https://stackoverflow.com/questions/34988277/write-once-in-linux-kernel-lists
read_once, write_once, barrier, volatile 관련 (Memory Functions)
- https://medium.com/@chenfelix/memory-barrier-684dcd3f7441
* typecheck, expression statement 관련
- https://stackoverflow.com/questions/10393844/how-does-the-typecheck-macro-from-the-linux-kernel-work
* icc_pmr_el1 관련
- https://developer.arm.com/docs/ddi0595/b/aarch64-system-registers/icc_pmr_el1
* round_up 관련
- https://medium.com/@arunistime/how-div-round-up-works-179f1a2113b5
</textarea>
</li>
<li class="file">
<a href="">017 (2019-09-30) : arch/arm64/kernel/head.S</a>
<textarea readonly rows="4" cols="128">
* statement expression 관련
- http://lvzuufx.blogspot.com/2015/07/c-gcc.html
</textarea>
</li>
<li class="file">
<a href="">018 (2019-10-05) : arch/arm64/kernel/head.S</a>
<textarea readonly rows="10" cols="128">
* priority masking 관련
- https://developer.arm.com/docs/ddi0601/latest/aarch64-system-registers/icc_pmr_el1
* GIC - Generic Interrupt Controller
- http://jake.dothome.co.kr/ic/
* typedef struct cpumask { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t; bitmask로 활용 관련
- http://jake.dothome.co.kr/cpu-api/
</textarea>
</li>
</ol>
</li>
<li>
<label for="menu-1-2">week [019 ~ 027] : init/main.c::start_kernel() → arch/arm64/mm/mmu.c::early_fixmap_init()</label>
<input type="checkbox" id="menu-1-2">
<ol>
<li class="file">
<a href="">019 (2019-10-12) : arch/arm64/mm/mmu.c::early_fixmap_init()</a>
<textarea readonly rows="64" cols="150">
* atomic64_or
- include/asm-generic/atomic-long.h
-> include/asm-generic/atomic64.h
1. arch/arm64/include/asm/atomic_lse.h
2. arch/arm64/include/asm/atomic_ll_sc.h
3. arch/arm64/include/asm/atomic.h)
* boot_cpu_init()
https://m.blog.naver.com/deviliangel/50187759904
* spinlock_check(_lock)
- https://0xax.gitbooks.io/linux-insides/SyncPrim/linux-sync-1.html
- https://junsoolee.gitbook.io/linux-insides-ko/summary/syncprim/linux-sync-1
* 구조체 변수를 선언하는 동시에 초기화하기
struct Person p1 = { .name = "홍길동", .age = 30, .address = "서울시 용산구 한남동" };
- https://dojang.io/mod/page/view.php?id=408
* 5.4 The Special Dot Symbol
The special symbol ‘.’ refers to the current address that as is assembling into.
Thus, the expression ‘melvin: .long .’ defines melvin to contain its own address.
Assigning a value to . is treated the same as a .org directive.
Thus, the expression ‘.=.+4’ is the same as saying ‘.space 4’.
- https://sourceware.org/binutils/docs/as/Dot.html#Dot
* void __init early_fixmap_init(void)
- https://sonseungha.tistory.com/457
* early_fixmap_init()
- https://isun2501.tistory.com/20
* bm_pte // which is boot time page tables
- https://junsoolee.gitbook.io/linux-insides-ko/summary/initialization/linux-initialization-5#early-ioremap-initialization
* arch_atomic64_or(), arch_atomic_or()
- arch/arm64/include/asm/atomic_lse.h
</textarea>
</li>
<li class="file">
<a href="">020 (2019-10-26) : arch/arm64/mm/ioremap.c::early_ioremap_init()</a>
<textarea readonly rows="24" cols="128">
early_ioremap_init() (arch/arm64/mm/ioremap.c)
- early_ioremap_setup() (mm/early_ioremap.c)
-- __fix_to_virt() (include/asm-generic/fixmap.h)
#define __fix_to_virt(x) (FIXADDR_TOP - ((x) << PAGE_SHIFT))
* 이른(early) 시간에 io 매핑이 필요한 경우 256K씩 최대 7개의 fixmap 매핑 공간을 사용하여 매핑을 할 수 있게 한다.
- http://jake.dothome.co.kr/early-ioremap/
- http://jake.dothome.co.kr/fixmap/
* fdt, dtb 관련
- http://jake.dothome.co.kr/dtb1/
</textarea>
</li>
<li class="file">
<a href="">021 (2019-11-02) : 통합 연습 스터디</a>
<textarea readonly rows="6" cols="128">
</textarea>
</li>
<li class="file">
<a href="">022 (2019-11-09) : 통합 연습 스터디 2</a>
<textarea readonly rows="6" cols="128">
</textarea>
</li>
<li class="file">
<a href="">023 (2019-11-16) : 통합 전 각 조별 스터디</a>
<textarea readonly rows="6" cols="128">
* pgprot_t 관련
- https://www.kernel.org/doc/gorman/html/understand/understand006.html
* create_pgd_mapping 관련입니다
http://jake.dothome.co.kr/map64/
</textarea>
</li>
<li class="file">
<a href="">024 ~ 027 : Slack 을 참고하여 확인 필요</a>
<textarea readonly rows="6" cols="128">
024 (2019-11-23)
024 (2019-11-23)
025 (2019-11-30)
026 (2019-12-07)
027 (2019-12-14)
</textarea>
</li>
</ol>
</li>
<li>
<label for="menu-2">week [028 ~ 054] : init/main.c::start_kernel() → arch/arm64/kernel/setup.c::setup_arch()</label>
<input type="checkbox" id="menu-2" />
<ol>
<li>
<label for="menu-2-1-0">028 (2019-12-21) ~ : arch/arm64/mm/mmu.c::fixmap_remap_fdt</label>
<input type="checkbox" id="menu-2-1-0" />
<ol>
<li class="file">
<a href="">028 (2019-12-21) : fixmap_remap_fdt</a>
<textarea readonly rows="4" cols="128">
setup_arch
- setup_machine_fdt
-- fixmap_remap_fdt 까지 진행
</textarea>
</li>
<li class="file">
<a href="">029 ~ 035 : Slack 을 참고하여 확인 필요</a>
<textarea readonly rows="8" cols="128">
029 (2020-01-04)
030 (2020-01-11)
031 (2020-01-18)
032 (2020-02-01)
033 (2020-02-08)
034 (2020-02-15)
035 (2020-02-22)
</textarea>
</li>
</ol>
</li>
<li>
<label for="menu-2-1-1">036 (2020-02-29) ~ : arch/arm64/mm/init.c::arm64_memblock_init()</label>
<input type="checkbox" id="menu-2-1-1" />
<ol>
<li class="file">
<a href="">036 (2020-02-29) : drivers/of/fdt.c::early_init_fdt_scan_reserved_mem()</a>
<textarea readonly rows="6" cols="128">
setup_arch
- arm64_memblock_init
-- early_init_fdt_scan_reserved_mem 까지 진행
</textarea>
</li>
<li class="file">
<a href="">037 (2020-03-07) : include/linux/cma.h::cma_declare_contiguous()</a>
<textarea readonly rows="7" cols="128">
setup_arch
- arm64_memblock_init
-- dma_contiguous_reserve (kernel/dma/contiguous.c)
--- dma_contiguous_reserve_area (kernel/dma/contiguous.c)
---- cma_declare_contiguous (include/linux/cma.h)
----- cma_declare_contiguous_nid (mm/cma.c)
------ cma_init_reserved_mem 이전 까지 진행
</textarea>
</li>
</ol>
</li>
<li>
<label for="menu-2-2-1">038 (2020-03-14) : arch/arm64/mm/mmu.c::paging_init()</label>
<input type="checkbox" id="menu-2-2-1" />
<ol>
<li class="file">
<a href="">038 (2020-03-14)</a>
setup_arch
- paging_init
-- map_kernel 까지 진행
</li>
<li class="file"><a href="">039 (2020-03-21)</a></li>
<li class="file"><a href="">040 (2020-03-28)</a></li>
</ol>
</li>
<li>
<label for="menu-2-3-1">041 (2020-04-04) ~ : drivers/of/fdt.c::unflatten_device_tree()</label>
<input type="checkbox" id="menu-2-3-1" />
<ol>
<li class="file">
<a href="">041 (2020-04-04) : drivers/of/fdt.c::populate_properties()</a>
<textarea readonly rows="7" cols="128">
setup_arch
- unflatten_device_tree
-- __unflatten_device_tree
--- unflatten_dt_nodes
---- populate_node (drivers/of/fdt.c)
----- populate_properties (drivers/of/fdt.c)
------ " if (!has_name) { " 이전 까지 진행
</textarea>
</li>
<li class="file">
<a href="">042 (2020-04-11) : drivers/of/fdt.c::unittest_unflatten_overlay_base()</a>
<textarea readonly rows="6" cols="128">
setup_arch
- unflatten_device_tree
-- unittest_unflatten_overlay_base 이전 까지 진행
</textarea>
</li>
</ol>
</li>
<li>
<label for="menu-2-4-1">043 (2020-04-18) ~ : arch/arm64/mm/numa.c::arm64_numa_init()</label>
<input type="checkbox" id="menu-2-4-1" />
<ol>
<li class="file">
<a href="">043 (2020-04-18) : drivers/of/*::of_*()</a>
<textarea readonly rows="8" cols="128">
setup_arch
- arm64_numa_init
-- of_numa_init (drivers/of/of_numa.c)
--- of_numa_parse_memory_nodes (drivers/of/of_numa.c)
---- of_address_to_resource (drivers/of/address.c)
----- of_get_address (drivers/of/address.)
------ of_get_property (drivers/of/base.c) 이전 까지 진행
</textarea>
</li>
<li class="file">
<a href="">044 (2020-04-25) : 슬랙에서 확인 필요</a>
</li>
</ol>
</li>
<li>
<label for="menu-2-5-1">045 (2020-05-09) ~ : arch/arm64/mm/init.c::bootmem_init()</label>
<input type="checkbox" id="menu-2-5-1" />
<ol>
<li class="file">
<a href="">045 (2020-05-09) : mm/sparse.c::memblocks_present()</a>
<textarea readonly rows="6" cols="128">
setup_arch
- bootmem_init
-- memblocks_present (mm/sparse.c)
--- memory_present (mm/sparse.c)
---- section_mark_present (mm/sparse.c) 이전 까지 진행
</textarea>
</li>
<li class="file">
<a href="">046 (2020-05-16) : mm/sparse.c::spare_init()</a>
<textarea readonly rows="6" cols="128">
setup_arch
- bootmem_init
-- spare_init (mm/sparse.c)
--- sparse_init_nid (mm/sparse.c)
---- sparse_mem_map_populate(vmemmap) (mm/sparse.c) ## v5.10.x 이후 사라짐
----- pfn_to_page. 까지 진행
</textarea>
</li>