claim page 시 page는 별도의 구조체이므로(spt table에 추가할) malloc 처리.
vm alloc with initializer 에서 타입에 따라 initializer를 구분하여 uninit_new에 넣음. spt find시 if문 형태 수정.
lazy_load file read 시 읽어서 넣는 주소를 page가 아닌 frame kva로 수정.
anon 형태 생성시를 이해하고, try handle fault에서 page를 할당받아오는 게 아니라, validate 체크로만 변경.(어차피 validate에 따라 claim함.) 조건문의 변수로 not present사용. page에 writable도 추가하여 조건 비교.
do_claim 에서 매핑하는, pml4 set 과정 추가.(나는 앞부분만으로 충분한줄 알았음.) hash insert는 애초에 spt insert로 vm initial 과정에서 이루어진다는걸 이해.
setup stack 설정. pa와 va를 각각 만들어 잇는다는걸 이해, pa는 vm alloc으로 va는 claim page로 가져옴. (내가 만들 파일 구조체 형태로 페이지를 추가할 수 있도록 메모리를 할당 받아오고 적절한 데이터를 매핑 및 추가.)(기능의 본질은 유저 스택에 페이지 크기만큼 쓸 수 있는 공간을 주는 것.)
스택임을 명시하는게 VM_MARKER_0인데 이건 더 확인해볼것.
spt 구현 수정. spt find page를 iteration이 아니라 hash find 내장 함수 사용. insert는 성공 여부를 반환하도록 수정.
vm get frame시 frame을 malloc으로 할당받아오고, kva를 주소를 가져오기 위해 palloc 해서 frame과 kva를 이어줌. frame은 정보를 담는 구조체고 주소는 단지 주소일뿐이라는 점을 알게 됨.
claim page는 단지 spt에서 대조하여 do claim으로 넘길 뿐이고, do claim에서 frame을 가져와 매핑하고 swap이 진행됨을 이해.
현재.
spt find page에서 뻑나는중.(hash_find 파트.)
그 외.
0x8등 not present여도
try handle fault로 빠져야하는데 안 빠지고
페이지 폴트를 알리고 끝나길래
make file을 수정해야하나 했는데
hash 구조체에 따라 좌우될 수 있음에
연관관계는 모르겠지만 아무튼 그러함.
(다른 사람의 버그 리포팅으로 유추.)
알아둘만한것
이 frame, kva, page, va에 대한 구분을
좀 더 빨리했으면 이해에... 도움이 되었을지도.
전반적 함수의 life cycle도 알락말락.
claim page는 정말 spt를 참조해서 page를 claim할 뿐이고
load segment 당시 initializer를 다 지정해주기때문에
fault handler는 claim page만 진행한다는걸 깨닫는것도 좀 걸렸고
(handler 자체도 not present해야 작동한다든가)
palloc 헷갈리고, malloc을 써도 되는지 헷갈리고,
기타 등등등이 개념은 알아도 코드 적용에
실제 어디가 무슨 함수인지 분명치 못하게 안 게 패인...

코드를 직접 보고
인자가 어디가 어떻게 넘어가고를 열심히 봤고
그것덕에 또 나름 채웠기는 했는데
그보다는 함수 명만 적어서
여기에서 무슨 작업을 해야할지
인자로 유추하지 말고
개념과 작동원리로 생각하는게 좋을뻔.
뭣보다 저번 프로젝트에도 나왔던
palloc이나 pml4 에 대한 이해가 충분치 않았던 것도 쪼끔.
(file을 list로 만들어서
elem 형식으로 추가했다면 그때 이미 malloc을 했었을수도..)
많이 틀렸지만...
스스로 알아냈더라면 물론 좋았기야했겠지만
그나마 빈칸 최선을 다해 다 채우고 대조한 거라
혼자서는...
절대 몰랐을듯...
(알더라도 일주일 후일듯...)
코어...는 모르겠고
진도...는 물어볼까
spt find page를 해결하고싶다...
해결하고 싶다...
30분 알고리즘
적어도 이 때까진
fork 전까지는 해결했으면 좋겠다...
너무 안 풀리면 가끔씩
다른 부분 개념 보며 스스로를 위로하기
배고프다
hungry...