와, 얼마만의 정식(?) 블로그 포스팅인지 모르겠다.
요 근래 OS 프로젝트를 하느라 거의 밤샘하다시피하면서 폐인 생활을 계속했었는데, 딱 하나 잘못 생각했던 것 때문에 거의 2일 이상을 날려먹었음을 깨닫고 그동안 짰던 priority donation 코드를 싹다 버리고 새로 짰다. -_- 2일 동안 밤새서 만든 코드보다 양도 더 적고 버그도 적었다.
그렇다면 그동안 했던 삽질이 헛수고냐라고 묻기 쉬운데 잘 생각해보면 꼭 그런 것 같지만은 않다. 그렇게 삽질을 하면서 어떤 버그나 문제가 발생했을 때 잠재적인 원인을 유추하는 스킬이 생기고 특히 이번 프로젝트를 통해 gdb 사용법을 좀더 자세히 알게 되었다.
어제의 작업 화면. 현재 버전에선 가운데 화면의 코드 중 절반 이상이 바뀌었다.
OS 커널 코딩은 SP 때와 상당히 다른 느낌이다. SP 때는 코딩량 자체가 많았지만, OS는 코딩량은 얼마 안 되어도(Pintos 처음 코드와 현재 내가 고친 코드를 diff 뜬다면 아마 100줄 정도밖에 안 바뀌었을 것이다) 한줄 한줄의 의미와 영향력이 엄청나게 중요해서 정말로 생각을 많이 해야 한다. 모니터를 보며, vi의 ctags로 이리저리 돌아다니며 계속 생각하고 모델링해야 하는 것이다. 또한 내가 처음부터 만드는 프로그램이 아니고 이미 Pintos라는 주어진 OS 골격 안에서 프로그램을 짜야 하기 때문에 다른 사람이 만들어둔 소스를 읽는 스킬도 중요한 것 같다.
SP를 들으며 "Segmentation Fault"에 익숙해졌다면 OS를 진행하면서 "Kernel Panic"에 익숙해졌다. -_- 이제 블루스크린이나 커널패닉이 떠도 개발자가 얼마나 고생했을까 하는-_- 동병상련(?)의 마음이 들 것 같다; 물론 데이터 날려먹으면 화는 나겠지만..;;
SP와 OS를 들으며 느끼는 거지만, 큰 규모의 디버깅이 힘든 프로그램을 짤 때는 다음을 꼭 지켜야 하는 것 같다.
- 하다가 막히면 일단 쉬자. 게임을 한판 하든 산책을 하고 오든 잠을 자든 다른 짓을 하고 다시 보면 새로운 아이디어가 떠오르는 경우가 많다.
- 오랫동안 짠 코드라고 버리기를 아쉬워하지 말자. 보다 나은 설계가 있다면 최대한 빨리 적용하고 테스트해보자. (물론 만일에 대비하여 버전관리 시스템을 사용하는 것을 권장한다)
- 잘 이해가 안 되는 부분이 있다면 다른 사람에게 물어보거나 같이 토론하는 것이 큰 도움이 된다. 직접적으로 답을 제시받지 못하더라도 남에게 설명하기 위해 스스로 문제를 정리하게 되기 때문이다.
이제 오늘 중으로 18개의 test-case 중 남은 2개에 해당하는 nested donation 구현만 끝낸다면 1번 프로젝트는 끝난다. 그러나 2번 프로젝트는 훨씬 더 많은 test-case가 기다리고 있다는 소문이..... OTL
- Tag
- CS330, OS, Project, 삽질, 운영체제, 프로그래밍, 플젝
- Response
- No trackback yet , 14 Comments
- RSS :
- http://daybreaker.info/blog/rss/response/675
Trackback URL : http://daybreaker.info/blog/trackback/675
Comments List
-
polarnara 2007/10/08 05:12 # M/D Reply Permalink
와.. 저도 이번학기에 gdb 써요..(..)
생각하는 게 많다니, 그 부분이 꽤 재미있을 것 같아요. 훨씬 간결하면서 강한 코드를 떠올려냈을 때 그 즐거움. 물론 떠올리기까지는 스트레스입니다만;-
daybreaker 2007/10/08 17:39 # M/D Permalink
확실히 gdb가 중요하죠. 디버거로 적절한 지점에 breakpoint 걸어서 내가 만든 코드가 실제로 언제 어떤 조건에서 실행되는지만 파악해도 모델링의 틀린 점을 찾는 데 큰 도움이 됩니다.
-
-
lifthrasiir 2007/10/08 06:09 # M/D Reply Permalink
무엇보다 처음에 문제를 정확히 파악하고 거기에 해당하는 로직을 명확히 기술해 놓는 게 중요하다고 봄. 나 같은 경우 팀메랑 열심히 의논해서 알고리즘을 확정지은 뒤에 코딩을 했는데, 사소한 코딩 실수 (thread_yield를 인터럽트 꺼진 상태에서 호출하거나...) 고치고 잘 돌아 가서 비교적 빨리 프로젝트를 정리할 수 있었다.
-
daybreaker 2007/10/08 17:51 # M/D Permalink
우리 조의 경우는 일단 semaphore 관련된 건 팀메가 해주었는데 donation 관련된 거는 팀메랑 같이 모델링했다가 실패해서 다 지우고 내가 다른 모델 세워서 다시 짜는 삽질을...; Test-case 단위로 접근하다보니 어디까지는 통과가 되는데 그 다음 것을 통과하려면 뜯어고쳐야 한다거나 하는 상황이 발생했지;
2번 플젝부터는 일단 문서부터 읽고 test-case 훑어보고 Pintos 코드 이해한 다음 설계 들어가려고 생각 중.
-
-
reshout 2007/10/08 08:58 # M/D Reply Permalink
제가 회사에서 일하는 화면이랑 비슷하네요. ㅋ 비스타는 쓸만한가요?
-
daybreaker 2007/10/08 17:43 # M/D Permalink
듀얼모니터의 유혹이 있으나 기숙사가 좁은 관계로 참고 있습니다;; 데스크탑이 고사양이라 그런지 비스타 전혀 버벅이지도 않고 아주 쾌적합니다.
-
-
haneul 2007/10/08 10:22 # M/D Reply Permalink
오호 OS 플젝이 pintos로 바뀐모양이네요 +_+a;
원래 삽질 한번하고 다시 짜면 잘 짜지죠 ㅋㅋ :)-
daybreaker 2007/10/08 17:43 # M/D Permalink
작년 가을학기부터 바뀐 걸로 알고 있어요. 조교분들도 석박사 과정에 계신 분들은 잘 몰라서 그때 수강했던 학부생들이 보조하고 있기도 하고 그렇습니다.;
-
-
puresaida 2007/10/08 17:22 # M/D Reply Permalink
버림의 미학이라..
종종 내게도 필요한 것이라 생각 되는군..
흐음~일교차 심한데 감기조심하고 집에서 보자:)-
daybreaker 2007/10/08 17:47 # M/D Permalink
적절한 때에 적절한 양만큼(-_-) 버리는 게 중요하지; 이번 주는 집에 갈 수 있을 듯. :)
-
-
요한 2007/10/08 19:29 # M/D Reply Permalink
아 끔찍해 ㅋㅋ
-
daybreaker 2007/10/09 16:22 # M/D Permalink
ㅠ.ㅠ;
-
-
안티테러 2007/10/09 13:31 # M/D Reply Permalink
여쭤볼게 이는데 가운데.. 큰 창에 여러화면으로 갈라져 있는 저 에디터는 빔인가요!? 어떻게 저렇게 칼라풀하고 여러화면으로 나눠서 쓸 수 있죠!???
-
daybreaker 2007/10/09 16:24 # M/D Permalink
원격 서버에 ssh로 접속해서 사용하고 있는 vim입니다. 기본 설정으로 쓰면 문법 강조를 하더라도 색이 어둡게 나오는데, set bg=dark 옵션을 주시면 저렇게 밝은 색깔로 글자가 표시됩니다. (뒷배경이 어두운 색임을 알려주는 거지요. 반대로 흰바탕의 콘솔을 쓰신다면 set bg=light라고 해주시면 됩니다)
화면을 나눠쓰는 것은 :sp 및 :vs (각각 가로, 세로 split) 명령을 이용한 것이고 화면 간 이동은 Ctrl+W h,j,k,l 키로, 화면 크기 조절은 [숫자] Ctrl+W <,>,+,-로 하실 수 있습니다. (자세한 건 vim 도움말을 찾아보세요.)
-