사실 저번주 목요일부터 week9였겠지

어제의 이야기

어제 공부한 것

저녁...
fork 함.

사실 fork밖에 못하긴 했음.
fork를 하면서 이것저것 고친것도 좀 있고.

거기 내에 duplicate_pte라고
페이지 엔트리를 복사하는 과정도 하고
(set으로 page 하는 줄알았는데
set은 다른 페이지를 참조해서 똑같이 세팅하는거고
그냥 newpage를 할당 받아서(malloc처럼)
memcpy로 parent page랑 똑같이 한다음
set으로 va와 이어주더만

뒤늦게 virtual mamory 파트를
깃북에서 읽으라는걸 너무 늦게 알아챔
여기서 봤으면 pte, page, va의 연관성을 바로 알았을텐데...

아무튼 va는 pml4라는 페이지테이블을 참조하고
그 페이지 테이블의 하나의 블록이 페이지인데
그 안에 있는 값이 페이지 테이블 엔트리, pte고
그걸 참조해서 PA를 찾아갈수 있음을 알아냄.

그렇게...하고
file_duplicate도 구현하라는데
앞에서 페이지 테이블도 복사하고 부모 프로세스 컨텍스트도 가져오는데
파일은 또 왜 이어야하지 고민했는데
파일 duplicate가 파일을 두개 만드는게 아니라
자식 프로세스가 갖는, 파일에 대한 포인터를 하나 더 설정해주는 거였음. 확실히... 포인터를 공유해서 쓰는건 좀 그렇지.

그치만 file 자체를 어떻게 조달하나 고민하다가
맨처음 process 시작 함수에서
load로 파일 열때 그 파일을 thread 자체에 저장하는걸 생각해서 그냥 thread 한테 꺼내오는 방식 씀..

또 fork에서는
child 프로세스에서는 fork 를 똑같이 타도 tid를 0을 반환하고 부모 프로세스는 child tid를 반환하거든

그래서 여기서 대체 어떻게 하냐 했는데
do_fork라는 것 자체가 자식 스레드만 탄다고 생각했는데?
자식 스레드가 부모 스레드를 똑같이 복사해서
얘도 fork를 다 탄다면? 특별히 어느쪽에만 flag를 세워서 true로 설정할 수도 없을 뿐더러
그 순간의 fork에만 fork를 막아놔야한다는게...
(예를 들어 부모가 fork했다고 한번 flag를 세우면
그거 접어두지않으면 자식 프로세스는 자기 손주를 못보는거임..)

어떤가 했더니
syscall 레벨의 fork에서 나눠주면 되겠더만
(만약 fork시 thread name이 자기와 동일하다면
그건 이미... fork된 나니까...)

tid_error도 그 때 유효한가 아닌가를
어떻게 판단하는지 몰라도 거기서 판단해서 넘기면 될거같고

마지막으로 아직 안돌려봤지만
exec이 남았는데 시간이 넉넉치 않았고
make check 해보니 close 같은 부분이
인터럽트 핸들러에 걸려서 커널 패닉이 나길래

new_fd를 못 받아오는 문제와 관련이 있나 싶기도 하고
(close 함수 자체가 쓰레드의 fd를 같이 참조해서 닫는건데
new_fd도 못 넘어오는 마당에 thread의 fdt가 잘 넘어올거라는 보장이 없으니.... name이야 잘 넘어오는데 애초에 왜 넘어오는지도 모르겠고.)

다른 사람 코드 보니 다 fd를 찾는건 process 파일 영역에서 해결하더라고?
확인하고 끝...

소감

흠 exec을 먼저 할 지 close 부터 쇼부 볼지 고민인데
exec도 골자만 짜놓고 close 쇼부 봐야지

오늘의 계획

변경 사항 및 일정

내일 2시 퀴즈
아니 여기 사람 있는데 강의실 불 꺼지네
아침에 온 사람이 불을 안 켰다 의 진실이 밝혀짐

오전

exec 골자 짜기...

낮

exec 골자를 마무리하고

30분 알고리즘

close 손보기...

저녁

close와 잘 이별하면
다른 함수도 예외처리 등 손보기...

오늘의 다짐

불 꺼지니 자면 딱 좋을거같긴함