[목표]
시스템콜 관련 공부를 하고 구현하기(진행중)
나만의 Pintos 루틴(티타임 대비)
모르는 키워드들을 공부 → Git book 소개부터 공부 → pintos 카이스트 강의 시청(생각보다 방향성을 잡는데 도움이 되고 깃북에 안나와있는 힌트를 얻을 수 있음) → 구현시도(그러나 각 파일별 주석과 기능들을 팀노션에 정리하면서 색인처럼 효율적으로 구축) → 동료학습 OR GPT(도움잘 안됨)
구현이 완료되면 노션과 벨로그에 정리함. 그러나 시간이 너무 걸렸다.
그러나 코드를 작성하기는 하는데, 정확히 어떤 이론으로 돌아가는지 파악이 어려움
10:00 ~ 12:00
어제 하다 못한 시스템 콜을 이해하고 구현합니다.
12:00 ~ 12:20
식사 진행
12:20 ~ 14:00
halt 테스트 케이스가 진행이 안됨에 따라 디버깅을 진행했다.
이게 halt만 구현되면 halt 테스트 케이스가 통과되는줄 알았는데 그게 아니다. write 시스템콜까지 구현해야 진행이된다. 그외의 process.c 에서 몇가지 부분만 수정했다.
운영진 티타임 (14:00 ~ 15:00)
오늘 운영진 티타임에는 Pintos에 대해 이야기 해보는 시간을 가집니다.
교육생분들과 나눈 이야기
- GDB 관련된 문제가 있었다. 툴을 잘 사용하면 좋을 것 같다.
- 흐름을 파악한다. ( pintos에서 컴퓨터 그림을 사용한 전체 흐름도를 완벽히 파악했다.)
그래야 컴퓨터가 작동하는 방식과 어디서 코딩을 하고 있는지 확인이 간편하다. 흐름파악에 오랜시간을 투자했다. - 코드를 바로 보면 이해 X
- 코어타임을 통해 효과적인 동료학습을 최대한 활용하였다. (물어보는건 모두에게 다 물어봤다)
- 코드를 냅다 들어갔다. 생각보다 막히는 부분이 많았음. 디버깅하며 고쳐갔다.
핀트os에서 함수들에 대해서 어느정도 추상적으로 어떤 코드의 의미를 확인하고 나중에 면접에서 발표할 수 있을 수 있다.
-> 면접을 하는 자리에서 핀트os에서 코드에 대한 분석 내용을 잘 작성하면좋을 것 같다. WIL을 작성하는 것이 좋다.
주니어 코치분들의 pintos 꿀팁
- 질문 많이 하는 것이 좋을 것 같다.
- LLM 같은 경우에는 잘 못알려주기도하고, 질문을 잘 못해도 알아서 잘 알아들어서 안좋음.
- 예쁘게 질문하고자 노력했다. 어떤 사고를 가졌고 어떤 식으로 풀어봤는데 왜 안됐는지 질문
- Git Book, 강의, PPT 자료를 많이 보았다. 정제된 지식을 습득하려했다.
- 그때 당시에는 해당에 관련된 내용에
- 개념공부를 충실히함(2~3일 동안 CSAPP, OSICP 읽음)
- 흐름 파악을 충실히 했음. (코드 작성전 칠판에 코드 Flow를 그려서 파악)
- 혼자서 하다가 안되면 다른 팀에 물어봄
- 과제를 해결한 후에는 팀원들하고 보상을 해야한다. 그래야 원동력 생긴다.(테스트 케이스 하나를 몇시간만에 해결을 했으면, 밖에 나가서 맛있는거 먹고…)
이동석, 김현수 코치님의 pintos 꿀팁(회사 프로젝트 관점)
- 지식보다는 코드를 해결하고자함.
- 테스트 케이스를 모두 패스하는 것이 중요하다. (그 테스트 케이스를 이해해야 패스할 수 있기 때문이다.)
- hex_dump를 사용하여 스택에 잘 쌓였는지 확인할 수 있다.
- 전체적으로 파악하는 그림을 그려보는 것이 중요하다. (중간에 밥을 먹는 등의 다른 일을 하다가 오면 리셋되서 힘들수 있다)
- 그림을 그리는데 주의해야하는게 자세히 그릴려고 하는 사람이 있다. 그러므로 필수적으로 구현해야되는 것만 그리기(파악 가능한 정도만)
- pintos라고 생각하지말고 3만 라인짜리 거대한 시스템을 이해한다고 생각하자. 큰 시스템을 디버깅을 한다. 쉬운일이 아니다.
- 각각의 테스트 케이스가 어떤식으로 돌아가길래 pintos를 검사하는건지 분석하기.
- pintos에서 함수 이름을 설명하면 이해못한다. 그러므로 시간을 들여서 우리가 짜는 함수명을 다른 사람이 알아들을 수 있는 함수로 바꿔서 TIL에 정리할 필요가 있다.(나중에 면접시 면접관이 이해할 수 있게끔)
→ 추상화된 문구들로 리메이크하여 재작성을 해보자.(기록!)
잘못된 길을 걸어갔을때는 어떻게 해야될까?
- 시스템을 볼때도 너무 깊숙하게 들어가면 수렁에 들어 간다. 그러므로 다른 시스템 같은경우는 잘돌아갈것이라고 생각을 하고 믿자. (내가 수정해야되는 부분만 살펴보고 수정하자)
- 정확히 Layer를 나눠두고 밖으로 나가지 않게끔 생각하자.
- 두가지 분류가 있다. 바텀업과 탑다운. 그러나 사람마다 구현하는 방식이 다르므로 모두 좋다.
- 본인에게 잘 맞는 방법을 채택하는 것이 좋다.
etc.
-
카이스트 EE와 카이스트 CS 내부 코드가 다르다. userprog에서 부터는 차이가 있을 수 있다. 그러나 큰 맥락(목표)는 같다. 그러므로 모든 자료 차이는 존재할 수 있다.
-
디자인 도큐먼트를 작성하기. 프로젝트를 시작했을떄, 어떤것들이 있고 뭘해야하는지 테스트 케이스를 확인하면서 정리하는 것이 좋을 것 같다.
-
그냥 너무 깊게 들어가지않고 해당 함수는 어떻게 추상화로 잘 되겠지~ 만의 마음이 좀 필요하다.
이번 코어타임을 통해 처음 시작을 할떄 어떻게 시작을할지 난해했는데, 칠판에 큰 흐름을 정리하는 방법이나 함수별로 이슈트레킹을 하는 방식을 알게됐다.
머지를 어떻게 하는지? (다른 그룹)
main에는 보통 잘 합치지 않는 분위기이다.
서로의 코드를 보면서 더 좋은 방향의 코드를 채택하여 나중에 병합시 충돌이 나지 않게끔 수정작업을 하시는 것 같다.
15:00 ~ 15:40
명석이형 systemcall.c 와 관련된 페이지 fault 문제를 디버깅을 통하여 파악했습니다.
결론적으로는 아직 정상적으로 작동하지 않는 시스템콜을 호출(exit) 시켜서 문제가 발생했습니다.
15:40 ~ 19:00
아까전의 디버깅한 내용을 정리하며 왜 문제가 발생했는지 확인 중입니다. 디버깅 내용을 정리 후 벨로그와 티스토리에 추가 내용을 작성하였습니다.
노션과 정리를 병행하면서 시스템 콜을 작성중이다. 생각보다 시간이 오래걸렸다… write가 작성되어 있어서 read를 작성했다.
19:00 ~ 20:00
아바티 이준홍 CTO님의 개발자 커리어 특강을 들었다.
시간이 남는다면, 나중에 포스팅하도록 하겠습니다.
20:00 ~22:00
운동 후 샤워를 하고 왔습니다.
22:00 ~ 00:00
KFC 시킬 준비 후 그전까지 다같이 놀다가 밥먹었다.
00:00 ~ 03:00
시스템콜을 이어서 구현하고 있다. read도 권호형이 작성한 write를 참고하여 구현했다.
open 구현하다가 시간이 오래걸릴 것 같아서 creat 먼저 자력으로 구현했다. 모든 테스트 케이스가 통과한다아아아ㅏ아!
디버깅을 통해 오류 2부분을 수정했다.
