[목표]
mmap 구현을 해봅니다.
팀원들 코드를 merge 해봅니다.
13주차 퀴즈를 진행합니다.
어제 노션에 쓴 TIL을 정리하고 있다.
벨로그와 티스토리는 정리완료했다.
mmap를 막상 구현하기 보다는 이해가 우선인지라 어떤식으로 구현해야되는지 확인을 해보았다.
식사를 하고 휴식을 가졌다.

아까 이해한 mmap를 통해 구현을 해보았습니다.
13주차 퀴즈를 진행했습니다. 대부분 페이지 관련된 내용이었습니다. 나중에 정리되는대로 복습 내용을 올리겠습니다.
운동을 하고 왔습니다.
유윤선 코치님 커피챗이 있습니다. 현업의 계신 분들의 임베디드 소프트웨어에 대한 정보를 말씀해주셨습니다. 관련 내용은 기밀로 부치겠습니다. (정리된다면 올릴수도...)
저녁식사를 하였습니다. 졸려서 잠을 자다 왔습니다.

mmap 중 do_mmap 부분을 작성중입니다. process.c의 load와 load_segment 함수 부분을 참고하여 작성중입니다. 기윤님의 코드를 참고하여 작성중입니다.
본 코어타임을 진행했습니다.
은수 코드를 정상화하기 위해 디버깅을 시도했습니다. 완료되는대로 머지를 진행해보겠습니다.
은수 코드의 문제점들
1. 이게 프로젝트2냐 3이냐에따라 ifdef VM으로 구분되어 있는데, 은수는 userprog의 함수를 편집해서 load인자가 안넘어왔다.
2. 그리고 주어진 함수들의 인자들을 마음대로 바꿔서 전체적인 흐름이 이상해졌다. 선언이 전체적으로 일관화되어있는데, 은수가 일부분의 함수만 바꾸면서 문제가 발생하였다.
3. 자잘한 실수가 있었다.
4. 인자를 바꾸고 static을 다른걸로 대체해서 문제가 생겼다. (제일 큰 문제)
→ 오늘은 채호형이 디버깅을 주도해보기로 했습니다. 어제는 제가 했으니 연습하는 것도 한가지 방법이라 생각합니다. mmap을 구현하면서 디버깅을 도와서 해결해보았습니다.
코어 타임중 머지를 시작했습니다. 다사 다난했지만, 여러 사람들의 도움으로 은수님이랑 채호형의 코드를 병합했습니다.
git checkout -b develop2 origin/develop2 : 깃브런치 로컬로 가져오기
브런치를 하나 파는 것이 맞다.(실험적인 일을 할때.)
git remote update : git 홈페이지에서 만든 브런치를 로컬에 업데이트 할 수 있다.
우린 팀의 깃허브 전략
1. 병합전에 편집한 페이지에 대해 개인 페이지를 만든다. 즉, 복제를 한다.
2. 지금까지 한 진행상황까지 로컬에 물리 백업을 실시한다.
3. 머지를 수행해본다. vm.c, process.c 등 충돌 사항이 많을 것이다. 한번씩 보면서 뭐가 다른지 보고 두개의 프로젝트를 합쳐도되고, 한명의 페이지로 대체해도 된다. 차피 나중에 본인코드 쓰는건 같다.
4. 한명과 머지를 완료하여 main에 올렸다면, 실행이 되는지 확인해본다.
5. 실행 후 다음 사람꺼까지 merge 해봅니다.
깃허브에 은수랑 채호형 코드는 병합이 됐지만, 내 코드는 아직 병합되지 않아서 수많은 시도를 해봤습니다. 그런데 제가 작성한 코드에 대한 내용이 업로드되지 않았습니다. 이유를 몰라서 결국엔 백업된 파일을 불러와서 develop5에 업로딩하였습니다. 깃허브는 알다가도 모르겠습니다.
나중에 소영님의 말을 들어보니, 전에 develop 이라는 PR을 하면서, revert를 했었는데 그러면서 커밋한 것이 날라가서 그럴 수 있다는 것을 알게되었습니다. 그래서 PR을 할때, 닫는건 상관없는데 revert는 사용 자제해야하는 것을 알게됐습니다. 어쨋든 해결했으니 다행입니다. 맨땅에 헤딩하면서 git hub를 알아가니 맨날 새로운 것을 알아가는 느낌입니다.
또한 코드를 합칠때 push로 충돌내서 올릴 수도 있지만, 합칠 대상의 브런치로 이동해서 git merge 합칠 브런치 로 충돌내서 해결하는 것이 문제생겼을때 해결하기 유리함을 알게됐습니다. 그리고 혹시 모를 사항을 위해 물리 백업을 하는 것도 좋은 방식인 것 같습니다.
내일 저의 코드로 바꿔보고 새로운 브런치를 파서 mmap를 돌려봐야겠습니다.