kkamagui의 작업실

안녕하세요 ^^ 저는 HP CP1215 체험단에 당첨된 kkamagui 라고 합니다. 프린터를 받은지는 이제 15일쯤 됐고, 그간 이것 저것 출력하면서 프린터를 돌려봤습니다. 출력 속도도 꽤 빠르고 컬러로 출력했을 때의 질도 상당히 괜찮더군요. 물론 사진을 출력할 수 있는 프린터에 비하면 출력물의 질이 좀 떨어집니다만, 일반 프리젠테이션용 자료 출력 같은 용도로 사용한다면 상당히 깔끔한 출력물을 얻을 수 있습니다.

일단 프린터의 전체적인 스펙에 대해서 한번 살펴보겠습니다. 물론 공짜로 받은 물건이니 만큼 금액적인 부분을 안 찾아볼수가 없겠지요? 아래에 같이 첨부했습니다.

인쇄 시스템
인쇄 기술	인라인 컬러 레이저 인쇄 기술
인쇄 기술 분석	HP ImageREt 2400
인쇄 속도(흑백, 일반 품질, A4)	최대 12ppm
인쇄 속도(컬러, 일반 품질, A4)	최대 8ppm
첫 페이지 출력(흑백, A4)	24초 이하("대기" 모드에서)
인쇄 품질(컬러, 고품질)	최대 600x600dpi
듀티 사이클(월간, A4)	최대 25000페이지
프로세서 속도	264MHz

용지 취급/용지
표준 용지함	1
최대 용지함 수	1
지원 용지 유형	용지(본드지, 브로셔, 색상지, 광택지, 레터헤드, 인화지, 일반 용지, 사전 인쇄 용지, 천공지, 재생 용지, 거친 용지), 투명필름, 레이블, 봉투, 마분지
표준 용지 크기	A4, A5, A6, B5(ISO, JIS)
사용자 정의 용지 크기	76x127∼216x356mm
권장 용지 무게	60~176g/m²
표준 입력량(낱장 용지)	최대 150매
표준 출력량(낱장 용지)	최대 125매
최대 출력량(낱장 용지)	최대 125매
양면 인쇄 옵션	수동(드라이버 지원 제공)
용지 취급	150매 입력 용지함, 125매 출력 용지함(인쇄면이 아래로)
최대 입력량(낱장 용지)	최대 150매

연결
표준 연결	고속 USB 2.0
최소 시스템 요구 사항	Microsoft® Windows® 2000, XP Home, XP Professional, Server 2003, Windows Vista®(32Bit 및 64Bit): 512MB RAM, 사용할 수 있는 하드 디스크 여유 공간 350MB, CD-ROM 드라이브, USB 포트 지원

출력 속도나 품질에 대한 부분을 제외하고 가격적인 측면만 본다면 상당히 괜찮다고 생각합니다. 컬러 레이저 프린터를 30만원이 안되는 가격에 구매할 수 있으니 말이지요. 예전에 잉크젯 프린터를 40만원 가까이주고 구매한 것을 생각하니 정신적인 데미지가 살짝 들어옵니다. ㅡ_ㅡa... 세상 참 좋아졌군요. ^^;;;

전체적인 평은 "크기가 좀 큰 것만 빼면 대체로 만족스럽다" 입니다. 프린터의 크기가 399 x 453 x 254 여서 좀 큰 편입니다. 저처럼 컴퓨터 책상이 좀 좁은 분들은 별로의 공간을 마련해야 하실 것 같습니다. ^^ 지금 바닥에 놓고 쓰고 있는데, 약간 프린터에게 미안한 마음이 드는군요. 얼른 책상을 하나 더 사야겠습니다.

잡담은 이쯤에서 마치고... 지금부터 프린터의 외관을 중심으로 HP CP1215 프린터의 특징을 살펴보도록 하겠습니다.

CP1215 프린터의 전체적인 모습은 깔끔한 편입니다.  앞면의 우측에 프린터의 상태를 표시해주는 상태 표시창을 가지고 있으며 프린터의 뒷편으로 전원 및 USB 단자를 연결할 수 있도록 되어있습니다. 따라서 필요한 선을 모두 연결한 상태에서도 깔끔하게 프린터를 사용할 수 있습니다.

오늘 간만에 드라이버 코드를 좀 만졌습니다. 예전에 만들어 놓은 동적 로딩 가능한 드라이버를 테스트할 일이 생겼거든요. ㅎㅎ 반응 속도가 굉장히 빨라야 한다고 해서 허접한 드라이버에 큐도 집어넣고, 나름 동기화도 처리하려고 뮤텍스를 사용했습니다.

그러다 보니 어느새 드라이버가 재부팅 되기 시작했습니다. 한참을 디버깅한 후에 알아내긴 했는데, 내가 이러고도 멀티코어 OS를 만든다고 할 수 있나 하는 생각이 들더군요. 코어 2개가 동작하니 싱글코어 일때 보다 더 Lock/Unlock 범위를 신경썼어야 하는데… ㅠㅠ 크윽... 역시 아직 멀었나 봅니다. 아주 기본적인 것 조차 헷갈리고 있으니... 이거 원 ㅎㅎ

덕분에 오늘 반성의 시간을 좀 가졌네요. 에혀... 역시 아직 멀었습니다. ㅠㅠ

밤이 늦었으니 오늘은 이만… ㅎㅎ 다들 좋은 밤 되세요 ㅠㅠ)-b

아유… 요즘 OS를 대충 만들어 놓은 거에 대해서 글을 좀 적고 있습니다. 글 재주가 워낙 없는지라 진도가 무지 안 나가는군요. 쩝쩝… 특히 앞부분은 기술적인 내용보다는 소설(??)에 가까운 내용들이라 더 진도가 안 나가는 것 같습니다. ㅡ_ㅡa... 그렇다고 안 쓸 수도 없는 일이니… 쿨럭;;;

겨우 겨우 서론 부분을 끝내 놓고 나니 이번에는 환경 구축이 문제로군요. GCC와 NASM을 사용해서 개발했기 때문에 이 두 가지만 설치 가능하면 이론상(?) 어디서든 OS를 개발할 수 있습니다. 물론 GCC가 64Bit 빌드 옵션을 지원하지 않으면 크로스 컴파일러를 만들어야 하는 부분이 추가되긴 하지만... 이러한 수고로움 정도야 OS를 개발하는데 드는 시간과 노력에 비하면 아무것도 아니지요. ㅎㅎ

아아~ 이것 참... 그냥 윈도우에서 개발하는 걸로 못 박기는 그렇고... 이것 저것 차이를 들어서 적자니 귀차니즘이 도지는군요. ㅠㅠ 이 일을 어찌해야... 뭘 정리하는 게 쉬운 일이 아닌 것 같습니다.

크으... 일단 오늘은 이만하고 내일 다시 해야겠습니다. 창작의 고통 + 잠이 몰려와서 죽을 것 같군요. ㅎㅎ

다들 좋은 밤 되세요 >ㅁ<)-b

구석에 짱박혀 있던 NDS를 발견하고 간만에 게임을 좀 해봤습니다. 작년 이맘때쯤 후배들과 작당해서 샀던 NDS인데… 사실 게임보다는 홈브루 만드는데 더 많이 썼군요. ㅎㅎ 그때는 밤이 새도록 홈브루를 만들었는데…  ^^;;; 그때 만든 NDS 홈브루는 http://kkamagui.tistory.com/category/NDS%20홈브루(Homebrew) 에서 보실 수 있습니다.

근래 PSP만 하다가 NDS를 하니 느낌이 많이 다르네요. 그때는 몰랐는데 역시 캐주얼한 게임은 NDS가 쵝오인 것 같습니다. PSP는 게임이 굉장히 화려하지만 뭐랄까요… 잠깐 잠깐 즐기기에는 좀… ^^;;; 그런 부분이 있더군요.

아아~ 이거 또 게임만 죽어라 하는 거 아닌가 모르겠습니다(설마?). 여튼 NDS 만세~!!!

에혀~ 이번이 두번째 워크샵인데, 워크샵을 한번 할 때마다 준비하고 처리해야 할 것이 산더미네요. 그래도 동기들끼리 준비를 같이하니까 그나마 다행인 듯합니다.

다들 늦게까지 술 마시고 신나게 노래 부르고 하던데, 전 워크샵 당일 아침에 목을 삐는 바람에 아무것도 못했습니다. 정확하게 말하자면 목을 삔 게 아니라 목과 어깨가 연결되는 뼈 부위를 삔 것 같습니다. 어깨를 올리거나 목을 숙일 때 마다 깜짝 놀랄 정도의 통증이 오더군요. 이런 경우는 또 처음이라 ㅋㅋ

아우… 몸은 피곤한데 할일이 또 산더미처럼 있어서 쉬지를 못하겠군요. ;)  일단 삽 좀 들고 일하다가 쉬어야겠습니다. 노가다 만세 >ㅁ<)/~~

오늘 확인해 보니 5장이 와있네요. ;)

초대장을 원하시는 분은 비밀 댓글로 연락주시면, 선착순 5분에게 드리겠습니다. ^^

ps) 12장으로 늘었군요. @0@)-b

아우~ 오늘 대충 만든 테스트에 속아서 테스트 케이스만 실컷 수정하다가, 심각한 버그를 발견했습니다. ㅡ_ㅡa… 제가 지금하고 있는 일은 기존 코드에 새로운 기능을 추가하는 것인데… 기존 코드가 잘 돈다는 보장이 없어서 상당히 난감할 때가 있습니다. 사람의 심리가 그렇듯이 자기보다는 남을 더 의심하는 법이지요. 재미있는 것은 기존 사원들 역시 자신들이 만든 코드는 의심하지 않고 제 소스를 먼저 의심한다는 겁니다.

오늘도 이것 때문에 문제가 살짝 있었습니다. 저희가 수정한 프로젝트로 테스트를 진행하던 기존 사원이 프로그램이 잘 안 돈다고 뭐라고 한 것이지요. 뭐라고 한 것에 대해서는 저도 경험이 많으니(??) 이해합니다만, 자신의 코드에 일말의 의심도 안하는 것에 충격을 먹었습니다.  ^^;;;

사실 수정한 코드에 문제가 발생했을 때, 코드의 어디가 문제인가를 가장 쉽게 알아보는 방법은 동일한 케이스로 기존 코드를 테스트하는 것입니다. 만약 기존의 코드가 잘 돈다면 제가 수정한 부분에 문제가 있는 것이고, 그렇지 않다면 기존 코드 자체에 있던 버그가 밖으로 나왔다고 볼 수 있습니다. 이러한 간단한 테스트로 디버깅해야 하는 범위와 시간을 줄일 수 있는 것이지요. 하. 지. 만 그냥 테스트 프로그램이 안 돈다고 말하면서, 기존 코드를 테스트 해보자는 제 말을 살며시 일축하더군요. ^^;;;;

테스트 케이스를 처음 봤을 때, 인덱스가 잘 못 들어가는 오류가 있어서 그 부분만 수정했습니다. 하지만 이게 시작이었습니다. @ㅠ@ 인덱스를 수정했는데, 이번에는 다른 포인트에서 계속 죽는 겁니다. ㅠㅠ 혹시나 하는 마음에 원래 프로그램을 돌려봤는데, 역시나 동일한 문제가 있었습니다. ㅡ_ㅡa… 결국 기존 사원이 와서 수정하는 걸로 마무리…!!!

쩝쩝… 허접하게 작성된 테스트 케이스 덕에 심각한 버그를 찾아낼 수 있었네요. 어휴… 이 버그를 모르고 그냥 릴리즈했다가 들어 먹었을 욕을 생각하면 등골이 오싹합니다. 릴리즈하고 난 뒤는 모두 제가 덮어쓰는 거라… 더 오싹하더군요. 앞으로는 기존 소스 및 수정한 소스 모두 테스트 해봐야겠습니다.

역시 테스트는 좋은 것입니다~!!!  테스트 만세~!!!!

금주 월요일부터 수요일까지 교육이라 아주 행복한 나날을 보냈습니다. 진정한 의미의 칼퇴근도 해보고 오늘은 마지막 날이라 후배와 함께 고기도 한그릇하고... 세상 천지 언제 이런 날이 다시 올지... ㅠㅠ

에혀... 어디 회사 안가고 계속 교육만 들을 수 있는 방법이 있으면 좋겠습니다. 크윽... 좀 쉬었더니만 진짜 회사 가기가 싫군요. 보나마나 일이 잔뜩 쌓여 있을 것 같은데... 콱 휴가나 내버릴까 싶기도 ㅋㅋ

아으... 어디 하고 싶은 일만 하고 살 수 없을까요? ㅠㅠ

오늘 간만에 글을 좀 썼습니다. 사실 썼다는 표현보다는 쓰고 있다는 표현이 더 맞는 것 같습니다만… ㅎㅎ  역시나 진도가 안나가는군요. 마이크로소프트웨어 기고할 때도 그랬는데, 역시 서문이 가장 어려운 것 같습니다.

저 같은 경우 본문은 소스 코드 설명이나 현상 설명 같은 내용들을 주로 넣으니 굳이 작문을 할 필요가 없는데, 서문 같은 경우는 그런 내용이 아니라 좀 가벼운 내용들 + 잡설 위주로 쓰는 편이라 상당한 고통이 따릅니다. 말 그대로 “작문”을 해야하니… 말 주변이 없는 저로서는 출산의 고통(?)과 맞먹는군요. ㅠㅠ 끄응… 그래도 넘어야 할 산이니만큼 꾸역꾸역 써야겠지요. ㅠㅠ

아래는 2004년 경에 만든 32Bit OS의 GUI 시스템 화면입니다. 내용물을 비교하자면, 지금 것과 비교하면 완전 최악이지만 GUI 시스템은 그리 크게 바뀌지 않은 것 같습니다. 그때도 상당히 고민했었는데… 지금 생각하니 그 당시는 너무 몰랐기 때문에 복잡하게 구현할 수 밖에 없었던 것 같습니다. 지금 코드는 훨씬 간단한데 말이지요. ㅎㅎ

 

마치 배경처럼 나와 있는 저 까마귀 그림은 제가 손수 그림판으로 그린 거라는… 지금 생각하니 저것도 웃기는 군요. 왜 저걸 그리고 있었을까나… ㅎㅎ 이궁…

에혀~ 밤이 깊었으니 자야겠습니다. 오늘은 좀 일찍 자는군요. ㅎㅎ 내일은 좀 더 일찍자야겠습니다. ;)

현재 윈도우 라이브 라이터로 글 쓰기 테스트를 수행하고 있는 중입니다. 로컬에서 작업을 할 수 있는 장점이 있다고 칭찬이 자자해서 한번 깔아 봤습니다. 상당히 괜찮군요. ^^;;; MS 워드처럼 맞춤법 검사도 해주고, 사진 같은 것도 쉽게 첨부할 수 있도록 되어 있습니다.

우와~~!! 앞으로 윈도우 라이브 라이터로 글 쓸 일이 많아 질 것 같은 예감이 드네요. ^^)-b 완전 짱~!!! 혹시 윈도우 라이브 라이터를 써 본적 없으시다면 이 기회에 한번 깔아 보시는 것도 괜찮을 것 같습니다. ^^

ps) 방금 테스트해 봤는데 태그도 지원되는군요. 멋집니다. ;)

 에구에구... 오늘 교육 끝나고 집으로 쏜살같이 달려와서는 그 동안 마음에 걸렸던 부분들을 수정했습니다. 사실 더이상 손대기에는 시간도 부족하고, 목표로 정한 것이 있어서 더이상 구현만 할 수는 없었다는... ㅠㅠ 그래서 완성도는 약간 떨어지지만, 프로토타입을 완료했습니다. ㅎㅎ

 지금까지 진행된 것은 멀티 태스킹 + 파일 시스템 + 동적 메모리 관리 + GUI 시스템 + 기타 시리얼, 마우스, 하드 디스크 드라이버 등등 정도 입니다. 뭐 많이 하긴했는데, 적어놓고보니 별거 없군요. ㅠㅠ 아래는 1.0 버전의 스크린샷입니다.

 파일 시스템이 추가되어서 시리얼로 실행파일을 매번 전송해서 실행하는 번거로움이 없어졌습니다. "Application Pannel"에서 "GUI Shell"을 실행한 다음 루트 디렉토리에 있는 테트리스 실행파일을 load 명령으로 실행하면 테트리스가 실행됩니다. ^^)-b GUI 쉘은 화면을 지우는 cls 명령과 디렉토리를 표시하는 dir 또는 ls 명령만 가지고 있습니다. 

 기념삼아 프로토타입을 테스트할 수 있는 파일을 올립니다. 아래 파일을 다운 받으셔서 압축을 푸신 다음 "qemu64MyOs.bat" 파일을 실행하시면 됩니다. 


 아아~ 오늘도 늦게까지 작업했더니 피곤합니다. ㅠㅠ. 일찍 끝낼 수 있었는데 QEMU가 Single Core 모드로 동작할때 IOAPIC 쪽을 사용하지 않는 걸 몰라서 한참 삽질했습니다. ㅡ_ㅡa... 커널이 잘못된 줄 알고 2시간동안 갈아 엎었습니다. 디버그 코드 덕에 겨우 알았다는... 싱글 코어일때는 PIC를 그대로 쓰도록 바꿔놔야겠군요. ㅎㅎ

 이크~ 저는 이만 자야겠습니다. 다들 좋은 밤 되세요~ ㅎㅎ

 

 

 이번주는 결혼식이다 뭐다해서 그렇게 많은 시간을 투자하지 못했습니다만, 막판 스퍼트해서  파일시스템을 추가하는데 성공했습니다. >ㅁ<)-b 사실 대부분의 코드는 윈도우 환경에서 시뮬레이션하면서 검증했기 때문에, 그냥 컨트롤 C+V 신공으로 끝냈습니다. ㅎㅎ

 그리고 내친김에 GUI 쉘에 dir 기능도 추가했습니다. GUI 쉘을 만든지는 좀 됬지만 귀찮아서 그냥 뒀는데, 점점 불편함이 커지더군요. 쉘 기능이 필요할때는 콘솔 모드 커널로 빌드해서 쉘을 쓰다가 다시 GUI 테스트할때는 윈도우 모드로 빌드해서 부팅하고... 이걸 수백번 정도 반복하다보니 그냥 만드는게 편하겠다는 생각이 들었습니다. 그래서 뚝딱~!!! 만들었습니다(사실 이 일이 더 많이 걸렸다는... ㅠㅠ).

 아래는 GUI 쉘로 루트 폴더와 이미지 폴더를 본 화면입니다. 깔끔하게 잘 나오는 걸 볼 수 있습니다. ㅎㅎ (이미지 윈도우는 /image/image0.img 파일을 읽어서 화면에 표시하도록 수정되었습니다)

 이거 뭐 점점 기능이 추가될수록 갈아 엎는 코드의 양도 많아지는군요. 이번에도 몇군데나 갈아 엎었습니다. ㅠㅠ 처음에는 간단한 OS를 만들자는 생각이었는데, 욕심이 자꾸 생겨서 이것도 추가하고 저것도 추가하게 되네요. 이렇다 언제 거사(?)를 시작하게 될지... ㅡ_ㅡa...

 진짜 내일 동적 메모리 할당쪽 알고리즘만 좀 더 수정하고, 거사를 시작해야겠습니다. 고칠게 있으면 거사를 진행하면서 고치던가 해야겠군요. ㅎㅎ

 내일 교육은... 또 물건너 간 것 같습니다. 푹 자다 올듯... ㅠㅠ
 다들 좋은 밤 되시길 ;)

 오늘 고향에 와서 여자친구랑 트럭을 봤습니다. 사실 여자 친구가 좀 기대를 하고 있던 터라 늦은 시간임에도 불구하고 봤었는데... 생각보다 그렇게 재미있지는 않더군요. ^^;;;

 유해진씨와 진구씨의 연기에는 별 불만이 없습니다만, 스토리의 전개나 진부함에 있어서는 거의 안습입니다. ㅠㅠ 어휴... 진짜 뭐라 할말이 없더군요. ㅠㅠ 딱 봐도 스토리 전개가 뻔~ 한게... 그냥 그런 스토리입니다.

 유해진씨와 진구씨의 연기때문에 5점 만점에 2점 줬습니다. 나머지는 걍 꽝... ㅠㅠ 다만 잔인함 하나는 일품이니, 잔인한 영화를 좋아하시는 분은 별 기대없이 보시는 것도 괜찮을 것 같네요. ㅎㅎ

 그나저나 아쉬움이 많이 남는 영화로군요. 쩝쩝... ㅠㅠ

 

 오늘도 집에 오자마자 컴퓨터를 키고 열심히 파일 시스템에 캐시를 추가하는 작업을 했습니다. 일단 어제 고민했던 문제 중에 FAT 영역 즉 클러스터 맵이 있는 영역에서 이상하게 캐시 히트가 낮게 나오는 문제를 뒤져봤는데... 역시나 문제가 있더군요. ㅎㅎ

 클러스터를 할당하는 코드가 클러스터 맵의 첫번째부터 마지막까지 검색하며 빈 클러스터를 찾게 되어있는데, 이런 경우 하드에 용량이 어느정도 차게되면 앞부분은 이미 대부분의 클러스터가 할당되어있음에도 불구하고 우직하게(?) 검색합니다. 따라서 클러스터 맵 영역의 캐시 또한 순차적으로 플러시되면서 거의 재사용되지 못하고 버려지게 되더군요.

 위와 같은 문제가 있어서 마지막으로 할당한 클러스터가 있는 클러스터 맵 인덱스를 저장하고, 클러스터 할당 요청이 올 때마다 가장 마지막으로 클러스터를 할당해준 클러스터 맵부터 검색을 시작하도록 수정했습니다. 이렇게 하니 거의 대부분 마지막으로 할당한 클러스터 맵에서 할당되서 거의 90%에 해당하는 캐시 히트가 나오더군요. 클러스터 맵을 쓰는 경우는 클러스터 할당/해제의 특성상 클러스터를 할당하려면 해당 맵을 읽어서 검색한 후, 할당했다고 마크를 해야하기 때문에 쓰는 경우는 100% 가 나왔습니다. 실로 엄청난 결과~!!! 이걸 실제 HDD에 적용할 경우 10번당 1번 하드를 읽는 것과 마찬가지기 때문에 시간을 엄청나게 절약할 수 있을 것 같습니다. >ㅁ<)-b

 하지만 이 기쁨도 잠시... 클러스터 영역을 캐시하는 기능도 추가했는데, 캐시 히트가... 20% 정도... ㅠㅠ 캐시 블럭의 개수를 128개 정도로 설정한 상태인데, 이를 더 늘리면 히트는 올라가겠지만 메모리 소모가 늘어나는 문제가 있기에 적당히 타협을 해야할 것 같습니다. 테스트 환경에서 캐시 블럭의 수를 2048개까지 늘리니까 40%까지는 히트가 올라가던데, 메모리 소모에 비해서 히트의 상승폭이 좀 낮아서 일단 다시 낮춰 놨습니다. 테스트는 가상으로 파일 3개를 만들고 랜덤한 파일 오프셋에서 랜덤한 사이즈를 읽고 쓰도록 하는 방법으로 하고 있는데, 아무래도 랜덤하게 읽고 쓰다보니 같은 클러스터가 다시 쓰이는 경우가 적은 것도 하나의 이유인 듯 합니다. 좀 더 고민해보고 캐시 블럭의 개수를 결정해야겠습니다. >ㅁ<)-b

 뭐든 구현하고 테스트할 때가 제일 재미있는 것 같습니다. 특히나 오늘처럼 예상하지 못한 결과가 나왔을 때는 더 즐겁습니다. 하핫~!!!
 헛.. 글고보니 내일은 고향에 가야되는데... 또 이렇게 시간이... ㅠㅠ 그만 자야겠습니다
 다들 좋은 밤 되세요. >ㅁ<)/~~

 어이쿠 또 시간이 이렇게나 흘렀군요. ㅠㅠ 방금 파일 시스템에 FAT(File Allocation Table) 영역에 해당하는 부분에 캐시 버퍼를 추가했는데, 대충 캐시 히트률이 60% 정도 나왔습니다. 생각보다 좀 저조한듯 하기도 하고... 일단 Sequential Write를 랜덤하게 돌려서 쓰고 읽고 검증하는 테스트를 돌리고 있는데, 에러가 안나오는거 보면 큰 문제는 없는 것 같습니다. 약간 문제라면... 캐시 히트률이 좀 낮은 게 문제라면 문제랄까요? ^^;;;;

 일단 캐시 알고리즘은 LRU(Least Recently Used)을 선택했고, Dirty 비트를 추가해서 Dirty 또는 Clean 중에 왠만하면 Clean인 놈을 선택하도록 했습니다. 물론 단순히 Age 만을 비교하는 것도 괜찮지만, 만약 쓰기가 수행된 캐시 버퍼 즉 Dirty 비트가 켜진 캐시 버퍼를 선택하게 되면 하드에 한번 더 써야하는 문제가 발생할 수 있어서 Clean을 우선적으로 선택하게 만들었습니다. Clean 인 놈은 쓰기가 수행되지 않고 읽기만 수행된 버퍼기 때문에 플러쉬(캐쉬에서 내보낼때)할 때 HDD에 안써도 되기 때문이지요. ㅎㅎ

 아흑... 원래는 더 일찍 끝났어야 하는데, lseek를 추가한다고 시간이 이렇게 흘러버렸군요. 처음에 예상했던 크기보다 점점 커지고 있어서 살짝 걱정이 됩니다. 어휴... 이걸 어떻게 해야될지... ㅠㅠ 그래도 일단 하던 작업은 끝내는게 맞는 듯 하니 이것까지만 해야겠습니다. ^^;;;

 내일은 알고리즘을 좀 손보고 데이터가 있는 클러스터 영역을 캐싱하는 기능도 추가해야겠습니다. 그리고 OS에 바로 옮겨봐야겠군요. ㅎㅎ 살짝 기대가 된다는... 과연 캐시를 사용하는 것과 사용하지 않는 것이 가상 머신에서 어떻게 차이가날지... 완전 기대됩니다. ㅎㅎㅎ

 그럼 내일 출근을 위해 전 이만 취침하러... ㅎㅎ
 다들 좋은 밤 되시길~ ;)

 주말 동안 쉬엄 쉬엄 파일 시스템을 설계했습니다. FAT 파일 시스템처럼 클러스터의 링크 형태로 말이지요. ^^ 최대한 간단하게 구현하려고 디렉토리 구조는 더욱 더 단순화시켰습니다. 그리고 코딩에 들어갔는데, 구현 초기에는 쉽게 쉽게 끝나는가 싶더니... 결국 또 복잡해지더군요.

 일단 멀티 태스크나 멀티 코어 환경에서 동기화 문제는 고려하지 않고, 단순히 파일 및 디렉토리 관련 API 만 만드는데, 꼬박 이틀이 걸렸습니다. 사실 API는 간단하게 만들고, 응용 프로그램이 잘 알아서 쓰도록하면 정말 간단한 구조를 유지할 수 있는데... 욕심이 생기다보니 이것 저것 많이 만들었습니다. 끄응.... ㅡ_ㅡa...

 덕분에 쓰기는 편해졌습니다만... 설명할게 많아져서 고민입니다. 현재 opendir, readdir, rewinddir, closedir, openfile, readfile, writefile, closefile, rewindfile, createfile, deletefile, createdirectory, deletedirectory까지 만들어져 있는데, 소스가 장난이 아니네요. 클러스터를 걸치는 녀석들 읽는거 처리하랴, Path 관련 처리하랴... 어휴... ㅠㅠ 하는 김에 rewindfile은 좀 더 고민해서 lseek로 만들어야겠습니다. 원래 lseek는 고려하지 않았지만... 만들다 보니 lseek 빼고는 다 만들었군요. ㅡ_ㅡa...

 만들긴 했는데... 과연 이 API가 얼마나 사용될지.... 삽질한건 아닌가 걱정이됩니다. ㅠㅠ
 억... 또 벌써 시간이 이렇게 됬군요.

 다들 좋은 밤 되시길.... ^^)-b

 ps) 아흑... 파일 동기화 문제는 또 어떻게 해결하지... ㅠㅠ

 헐... 당첨된지는 한 두달 된 것 같은데, 이제서야 프린터를 받았습니다.  첫 인상은... 뭐랄까요... 묵직한게 덩치가 좀 있어보인다랄까요? 컬러 레이져 프린터라서 그런지 토너가 4개가 들어가더군요. 헐헐헐... 프린터는 옛날에 엄마를 졸라서 샀던 컬러 잉크젯 프린터가 처음이자 마지막이었는데, 그거랑은 좀 많이 차이가 나더군요. ^^;;; 쿨럭..;;;;;

 기간 내에 리뷰 한개는 필수던데, 조만간 하나 써서 올려야겠습니다. 오전에 잠깐 시험 출력을 해봤는데, 굉장히 만족스러워서 살짝 기대하고 있습니다. ㅎㅎ 스펙 문서를 한 묶음 뽑아서 테스트해봐야겠습니다. ^^)-b

 앗싸~ 득탬~!!! >ㅁ<)-b

 아이쿠... 원래 계획은 좀 더 진도를 나가는 거였는데... 그 동안 무리를 좀 했더니 저녁에 잠깐 졸았습니다. 한 40분 잤으니 존거 치고는 시간이 좀 길군요. ^^;;;; 아무리 피곤해도 존적은 별로 없는데... 몸이 좀 피곤하긴 한가 봅니다. 그러거나 말거나 할꺼는 해야하니 세수 한판하고 또 진도 나갔습니다.

 일단 어제 대충 만든 테트리스를 좀 수정해서 블럭 색깔하고, 내부 알고리즘을 좀 정리했습니다. 원래 테트리스가 그리 복잡한 알고리즘이 필요없는 게임이라... 알고리즘이라는 말을 쓰기도 부끄럽습니다만... ㅡ_ㅡa... 발로 짜다보니 도저히 안되겠더군요. ㅎㅎ 내일쯤 정리되면 한번 올리겠습니다. ^^;;;;

 테트리스를 수정한 뒤에 한참을 고민했습니다. 이제 더 뭘 구현해야 하는가.... 가만히 보니 3개 정도가 더 남았더군요. 디지털 시계, 텍스트 뷰어, 이미지 뷰어 정도 남았던데... 디지털 시계는 텍스트로 날짜와 시간만 표시해줄 생각이니 크게 어렵지는 않을 것 같고... 텍스트 뷰어는 말 그대로 뷰어니까 그냥 텍스트만 출력해주면되니 이것도 별로 어렵지 않을 것 같았습니다.

 그렇다면 남은 것은 이미지 뷰어인데, 어떤 파일 포맷을 사용할 것인가가 문제더군요. 가장 쉽게 처리할 수 있는게 BMP 파일 형식인데... BMP도 다양한 버전이 있기 때문에 어떤걸 해야할지 고민이 됬습니다. 그러다가 문득 NDS 홈브루를 개발할때 만들었던 KNG(kkamagui NDS Graphic) 파일 포맷이 생각나서 그걸 사용하기로 했습니다. NDS 홈브루도 16bit Color로 설정되어있고, 마침 지금 만드는 OS도 16bit Color로 설정되어있으니 큰 수정없이 사용할 수 있을 것 같았습니다. KNG를 사용하는 NDS 홈브루는 http://kkamagui.tistory.com/49 와 http://kkamagui.tistory.com/468 에서 보실 수 있습니다.


 위의 화면은 수정된 테트리스와 그 뒤로 이미지 뷰어가 실행된 화면입니다. 이미지는 KNG로 변환해서 OS에 시리얼로 전송하는 방식으로 했습니다. KNG를 사용한 덕분에 작업이 상당히 빨리 끝났습니다. ^^;;; 이것 저것 많이 만들다보니 이런 날도 오는군요~ 좋구로 ㅎㅎ

 작업을 진행하면서 느끼는 QEMU의 장점은 TCPIP로 가상 시리얼을 연결할 수 있어서 굉장히 편리하게 시리얼 통신을 할 수 있는 점입니다. 속도도 굉장히 빠르고 QEMU 내부적으로 버퍼 관리도 해주니 OS에서 구현된 허접한 시리얼 드라이버로도 잘 됩니다. 덕분에 귀찮은 작업이 얼마나 줄었는지... ㅠㅠ)-b QEMU 만세~!!!

 아아... 벌써 또 시간이 이렇게 됬군요. ㅠㅠ 언제쯤 일찍 자려나... 그러려면 집에 굉징히 일찍오던지... 아니면 컴퓨터를 안켜야하는데, 둘다 실현 가능성이 낮군요. ㅠㅠ 거의 다 완료될때까지 잠을 줄이는 수 밖에는 없을 것 같습니다. 아흑....

 그럼 다들 좋은 밤 되세요. ^^)/~

ps) 헛... 이런 잠결에 만들다보니 화면에 있는 이미지 뷰어에 스펠링이 틀렸군요. 이런 ㅠㅠ

 헉헉... 아이구 머리야... 예전에 만든 소스를 긁어다 붙이는 것도 힘들군요. ㅎㅎ 금방 끝날줄 알았는데... 벌써 시간이 이렇게... 일단 아래는 실행한 화면입니다. 아직 프로토타입의 형태라서 버그도 좀 있고, 상태도 별로 안좋습니다. ㅎㅎ


 자세한 내용은 내일 올리겠습니다. 좀 늦어서... ㅠㅠ)-b
 그럼 다들 좋은 밤 되세요 >ㅁ<)-b

 이제까지 GUI 어플리케이션은 모두 커널레벨에서 동작하는 커널 스레드와 같은 개념이었습니다. 즉 커널 코드에 포함되어있으며, 스택만 별도로 사용하는 존재였지요. ^^;;; 그래서 "어플리케이션"이라고 확실히 부를 수 있는 유저 레벨 태스크를 이용해서 GUI 어플리케이션을 만들어봤습니다.

 위의 화면에서 좌측 상단에 보이는 User Level Application이라고 표시된 윈도우가 유저 레벨에서 동작하는 GUI 어플리케이션입니다. OS 코드가 아주 간단하지만, 현대 OS가 갖추고 있는건 쪼금 쪼금씩 구현해 놓은지라, 당연히 커널 영역에는 접근하지 못하고 시스템콜(System Call)을 통해서만 커널 함수를 쓸 수 있습니다. 다만 아직 GUI 관련 시스템콜이 그리 많지 않아서 덩그러니 윈도우 기본 화면만 표시하고 있다는... ㅠㅠ 원래는 Hello, World를 찍어야하는데 시스템 콜을 만드는게 귀찮아서 그냥 뒀습니다. ㅠㅠ 너무 늦게 퇴근해서... ㅠㅠ

 그리고 유저 레벨 프로그램은 역시 커널과 별도로 빌드해서 실행하는게 제 맛이기 때문에, 별도로 elf 파일을 생성했고 지난번에 만든 File Downloader를 통해 OS에 전송했습니다. OS에는 당연히 윈도우 버전의 File Downloader를 만들었구요. ㅎㅎ 위의 화면에서 가운데 있는 것이 윈도우 버전의 File Downloader 입니다. Memory Monitor의 그라데이션 태스크 바를 그대로 썼습니다. ㅎㅎ 그러고보니 스프링노트에 ELF 재배치에 대한 글을 적어놨었는데, 깜빡했군요. 언능 마무리해서 포스팅해야겠습니다. ㅎㅎ

 시간이 지날수록 점점 커지는 걸 보니 흐믓합니다. ^^ 이제 조금만 더하면 되겠군요. ㅎㅎ 내일은 좀 일찍오면 테트리스를 만들어 올려봐야겠습니다. 그리고 가능하면 텍스트 뷰어나 BMP 뷰어같은 것도 만들어봐야겠네요. ㅎㅎ

 어이쿠 벌써 이렇게 시간이.... 전 이만 자러가야겠습니다.
 다들 좋은 밤 되세요 ^^)/~

 오늘도 오후에 일어나서 어김없이 RSS를 돌고 있었는데, 꽤나 좋은 글이 있어서 링크를 남겨 놓습니다. 원문은 http://www.dal.kr/blog/001783.html 에서 보실 수 있습니다.

 이 글의 내용을 요약하자면 최근 들어 저작권 침해로 고소를 당한 블로거들이 계속 늘고 있고, 그로 인해 합의금 명목으로 돈을 뜯기는 블로거들도 늘고있다는 것인데... 컨텐츠를 악질적으로 업로드하는 경우가 아니라면 기소유예 처벌을 받는 정도라는 군요. 물론 무죄는 아니랍니다. 다시 걸릴 경우는 처벌이 가중되니, 주의를 해야겠지요. ^^;;;;

 세상이 무서워져서 블로그에 뭘 하나 올리기도 겁나는 세상이 됬습니다. 저작권도 중요하지만, 그만큼 자료의 공유도 중요하다고 생각하기에... 그냥 조심하는 수 밖에 없겠군요. ㅎㅎ ^^;;;;;;

 에휴~ 세상이 무섭습니다. ㅠㅠ)-b

 헥헥... 추석 이후에 전주 칼퇴를 목표로 열심히 일찍 퇴근했더니만, 이번주는 꽤 많은 시간을 투자할 수 있었습니다. 덕분에 고민도 많이 했고, 기능도 여럿 추가했습니다. 일단 아래 스크린샷 먼저 보시죠. ^^)/~

 가장 큰 변화는 어플리케이션 패널(Application Pannel)을 추가해서 굳이 GUI Shell을 통하지 않고서도 프로그램을 실행할 수 있게 한 것과, CPU 및 메모리 상황을 표시하는 어플리케이션이 추가된 것입니다.

 어플리케이션 패널은 마우스가 위치했을 때 해당 항목을 붉은 색으로 바뀌게 하여 사용자로 하여금 알기 쉽게 한 것이 포인트입니다. 제가 원래 GUI쪽은 거의 신경을 안쓰는 편인데... 이번은 저 혼자만 볼게 아니라서 신경을 좀 썼습니다.

 CPU 모니터는 일정 시간동안 CPU 부하 및 현재 대기중인 태스크의 수를 표시하도록 되어있습니다. 숫자만 덩그러니 표시하는 건 좀 없어보여서 아래에 그래프도 같이 표시하도록 했습니다.

 메모리 모니터도 CPU 모니터와 비슷한 방식이지만, 좀 다른 점은 아래에 사용량 그래프에 그라데이션 처리가 되어있는 점이랄까요? ㅎㅎ 메모리 사용량이 높아지면 게이지가 점점 올라가면서 붉은 색 계통으로 바뀝니다. 굳이 그럴 필요 없지만... 왠지 뭔가 변화를 줘야할 듯 해서.... 나름 많이 신경썼습니다. ㅡ_ㅡV...

 그외 소소한 변화는... 타이틀 바를 좀 더 진하게 한 것과, GUI쪽에 일부 최적화를 수행한 것 정도입니다. 크게 눈에 보이지는 않지만, 화면을 그리는 속도가 약간(??) 더 빨라졌습니다. ^^  와우~!!!

 아참~ 가운데 보이는 시커먼 화면은 방금 추가된 따끈 따끈한 GUI Shell 입니다. 알맹이는 Console꺼를 그대로 쓰면 되기 때문에, 화면만 먼저 만들었습니다. 처음에는 검은 바탕에 하얀 글씨였는데, 맨 처음 만들었던 32bit OS 생각이 나서 검은색 바탕에 녹색(메트릭스 스타일??)로 바꿨습니다. 한때 선망의 대상이던 모노크롬 모니터처럼 말이지요. ^^;;;;

 어휴~ 만들다보니 상당히 많이 왔습니다. 이제 파일 다운로더 프로그램과 테트리스 정도 만들고 거사(?)를 시작할 생각입니다. 이 정도면 남에게 보여줘도 부끄럽지 않을 것 같으니 말이지요. ㅎㅎ 그나저나 70KByte도 안되는 크기로 참 많은 일을 할 수 있군요. 예전에는 몰랐는데 말입니다. ;) ㅎㅎ

 아래는 지금까지 작업한 내용을 실행해 볼 수 있는 파일입니다. 예전과 마찬가지로 qemu64MyOs.bat 를 실행하시면 됩니다.


 일단 밥 좀 먹고 다시 작업을 해야겠군요. ㅎㅎ
 그럼 다들 좋은 하루 되세요 ^^)/~~~


ps) X 버튼을 눌렀을때 윈도우 및 태스크를 종료하는 기능을 추가했습니다. 그 동안 귀차니즘으로 안했었는데... 더이상 미룰 이유가 별로 없더군요. ㅎㅎ 첨부파일은 최신으로 새로 올렸습니다. ^^)/~

 요즘 컴퓨터를 하는 시간이 너무 길어져서 눈도 쑤시고 다시 어깨도 결리기 시작했습니다. 컴퓨터에 집중하다보니 적절한 휴식시간을 갖지 못한 탓이 큰 것 같더군요. 그래서~!!! 회사에서 장난삼아 깔아봤던 Eye Defender라는 프로그램을 집에다 깔았습니다.

 Eye Defender라는 녀석이 뭐하는 녀석이냐면~!!! 바로 일정시간이 지나면 휴식화면을 표시해주는 프로그램입니다. 화면 전체로 뜨기때문에 깜짝 깜짝 놀란다는 단점이 있긴하지만, 그 덕분에 아무 생각없이 눈을 풀 수 있어서 좋은 것 같습니다.

 Eye Defender는 무료 프로그램이고 http://eterlab.com/eyedefender/ 에서 다운받을 수 있습니다.
 휴식 화면으로는 눈 체조와 그림을 선택할 수 있는데, 기본으로 설정되어있는 그림이 특히 예쁘더군요. ㅎㅎ 아래가 그 사진입니다. ^^

 간단히 시작한 일인데... 버그가 나오는 바람에 연짱 7시간 정도 디버깅한 것 같습니다. ^^;;; 멀티 코어라는걸 자꾸 까먹고 작업을 하다보니 이상한 고정관념에 사로잡혀서 제대로 코딩을 안했더군요. ㅠㅠ)-b 크윽... 오늘은 꼭 기억할껍니다. ㅠㅠ 이렇게 허접할수가...

 멀티 코어임에도 불구하고 CPU가 초기화되는 순서가 0번부터 순차적일꺼라는 말도 안되는 생각을 계속 하고 있었습니다. 그래서 코딩도 순차적으로 CPU가 초기화 되니 스택도 순차적으로 할당해 주도록 했더군요. 허나 실상은... 초기화 되는 순서를 아무도 모른다는... ㅠㅠ 그래서 CPU의 ID를 직접보도록 수정했습니다. 끄응... ㅡ_ㅡa...

 그리고 막판에 짬을 좀 내서 CPU Monitoring Application을 추가했습니다. 원래 이게 목적이었는데, 장난삼아 Dual Core에서 Quad Core로 QEMU 옵션을 변경했다가 버그를 발견하고 디버깅만 주구장창했다는... 내일 출근은 또 어찌할지... 머리도 띵하고... 흑흑....

 아래는 급히 찍은 스크린샷입니다. Quad Core로 만들어 놓고 실행시킨 화면인데, 원체 허접하게 CPU Load를 계산하는지라... 별로 믿음직스럽지 못하군요. ㅎㅎ 그래도 된다는데 의의를... ^^;;; 시험삼에 Hexa Core(16개)까지 QEMU에서 테스트해봤는데, PC도 버벅거리고 QEMU에서 속도가 제대로 안나오더군요. 그나마 Quad Core까지는 쓸만한 것 같습니다.

 어휴... 테스트를 제대로 안해보고 거사를 시작했다면 어찌됬을까 아찔합니다. ㅠㅠ 역시 여유를 갖고 검토하는 시간을 갖길 잘한 듯 합니다. 에혀~

 이제 자야겠군요. 내일 하루종일 좀비모드로 지낼 것 같다는... ㅠㅠ
 다들 좋은 밤 되세요 ;)

 다들 즐거운 추석 연휴를 보내시고 계신가요? ㅎㅎ 저는 할머니댁에 당일치기로 갔다오는 바람에 시간이 많이 남아서 오늘도 어김없이 OS를 만들고 있습니다. 이런 걸 보면 역시 프로그래머가 천직인 것 같네요. ㅎㅎ ^^;;; 다만 좀 아쉬운 점이 있다면 마제스터치 키보드와 함께하지 못하고 허접한 삼성 멤브레인 키보드를 치고있다는 것... 기계식 키보드를 치다가 멤브레인 키보드를 치니 끝까지 눌렸는지를 확실히 알 수 없군요. ㅡ_ㅡa... 오타 작렬입니다. ㅠㅠ

 잡담은 이쯤하고... OS 개발도 거의 막바지로 가고 있어서 그 동안 고민했던 것들을 하나, 둘 마무리하고 있습니다. 옛날부터 OS를 몇번이나 뒤엎고 다시 들고 있지만, FPU 즉 실수 연산에 대해서는 그리 깊게 고민하지 않았습니다. 왜냐하면 finit, fxrstor, fxsave와 같은 멋진 어셈블리어 명령어들이 x387 Coprocessor의 상태를 관리해줬기 때문이지요. 그때는 단순히 이 명령들만 호출하면 된다고 생각했습니다. ^^;;

 그런데 막상 해보니 실상은 좀 다르더군요. ㅡ_ㅡa... fxsave 및 fxrstore를 이용해서 FPU 상태를 저장/복원했을 때 사용되는 메모리의 크기는 총 512Byte 입니다. 이건 상당히 큰 사이즈입니다. @0@)/~!!! 이것을 만약 Task Switching 시마다 저장/복원을 한다고 가정하면 Core에 있는 Register를 저장/복원하는 크기보다 더 크기때문에 거의 2배 정도의 Context Switching 시간이 걸립니다. ㅡ_ㅡa... 무시무시한 시간이지요.

 요 며칠동안 고민을 많이 했었는데, 가만히 생각해보니 뭔가 답이 나오더군요. Task 중에 FPU를 사용하는 Task가 여러개 있다고 가정하면, 인코딩 프로그램과 같은 프로그램을 제외하고는 실수 연산이 그리 빈번하지 않습니다. 즉 Task의 전체 코드에 비해 FPU 연산이 차지하는 비중이 작다는 것이지요. 그리고 또 한가지 포인트는 모든 Task가 FPU를 사용하는 것은 아니라는 겁니다. 경우에 따라 정수 연산으로도 충분한 Task가 있으니까요. ^^

 그래서 OS에서 마지막으로 FPU 연산(mmx, sse, sse2, sse3관련 어셈블리어 명령 사용)을 사용한 Task를 저장하고 있다가, 어떤 Task가 FPU 연산을 수행하면 마지막으로 사용한 Task와 비교해서 처리하는 방식을 생각했습니다. 사실 이 방법은 INTEL 문서(Volume 3)에도 나와있는 방법입니다. ^^;;; CR0 레지스터의 TS bit를 잘 사용하면 FPU 연산이 발생할때마다 7번 Exception이 발생하게 할 수 있고, 이것을 이용해서 처리하도록 가이드가 나와있습니다.

 제가  사용한 간략한 알고리즘은 아래와 같습니다.

 위와 같은 방식으로 총 300개의 FPU Task를 생성해서 돌려봤습니다. 처음에 FPU 상태를 저장하지 않았을때는 FPU가 여기저기 Task에서 건드려져서 정상적으로 계산 결과가 나오지 않더군요. 하지만 위와 같은 알고리즘으로 구현하고나니 계산 결과가 정확하게 나왔습니다. >ㅁ<)-b

 이렇게 또 한고비가 넘어가니 기분이 좋습니다. ㅎㅎ 잠깐 나갔다 와서 다른 장난(?)도 좀 쳐봐야겠군요. ㅎㅎ
 다들 즐거운 연휴 보내세요. ^^)-b



 

 곰탕님께서 Natural Ergonomic 4000과 마제스터치 중에 어느 것이 장시간 타이핑에 좋냐고 덧글로 물으셨는데, 내용이 길어져서 덧글로는 좀 힘들더군요. ^^;;; 그래서 이렇게 글을 한자 적어봅니다. ㅎㅎ

 사실... Natural Ergonomic 4000(이하 어고노믹)과 마제스터치 클릭(이하 마제)는 전혀 다른 타입의 외관과 내부 구조를 하고 있어서 비교하기가 좀 힘듭니다. ^^;;; 그래도 억지로 비교를 해보자면...

 어고노믹은 이름 그대로 네추럴 키보드 형태를 하고 있어서, 처음에 적응하기 좀 힘든면이 있지만 적응하고 나면 손과 손목이 굉장히 편안합니다. 손과 손목이 편안하니 어깨의 긴장도 적지요. ^^ 다만 타격감은 기계식 키보드에 비하면 좀 떨어집니다.


 마제는 기계식 스위치를 사용하기 때문에 일반 키보드는 따라올 수 없는 타격감을 자랑합니다. ^^ 표준 키보드의 형태를 하고 있으니 굳이 키보드에 적응할 필요도 없습니다. 굳이 한가지 들자면 소음에 적응을 해야한다는... ^^;;;; 하지만 소음이 좀 적은 마제 키보드를 사면 어느정도 해결되니 큰 문제는 아닌 듯 합니다.


 회사에서 장시간 타이핑을 하시고, 그것 때문에 손과 손목에 무리가 가신다면... 네추럴 방식의 키보드를 추천드립니다. 저도 지금 마제를 쓰고 있지만, 이게 표준 형태의 키보드이다 보니 어깨가 다시 결리기 시작하더군요. 어고노믹을 쓸때는 괜찮았었는데 말입니다. ^^;; 하지만 마제의 타격감이 워낙 좋다보니 마제를 포기하기는 힘들고... 대신 어깨를 마구 돌려가면서 사용하고 있습니다. ㅎㅎ

 나중에 시간 나시면 한번 가서 직접 쳐보시는 것도 괜찮을 것 같습니다.
 그럼 꼭 몸에 맞는 키보드를 고르시길 바랍니다. ;)

 어제 급히 Application Level, 즉 User Level을 추가했다가 낭패를 크게 봤습니다. ㅡ_ㅡa...  첫번째는 아무 생각없이 Supervisor Mode로 맵핑되어있는 Paging 때문에... 두번째는 요상하게 설정된 User Level Descriptor 때문에... 세번째는 Segment Selector에서 잘못된 RPL Field 때문에... 네번째는 RFLAGS에 있는 IOPL 때문에... 다섯번째는 Interrupt 발생 시, User Level에서 Kernel Level로 변경되어 자동으로 발생하는 Stack Switching 때문이었습니다. 헥헥... 나열하니 이거 끝이 없군요. ;)

 원래의 목적은 Application Level에서 커널 함수를 사용할 때 Interrupt를 사용해서 Kernel 레벨로 바꾸고, Interrupt를 활성화 한 상태에서 커널 코드를 실행하는 것이었습니다. 이렇게 하면 인터럽트 불가로 동작하는 시간이 줄어들기 때문에 인터럽트에 좀 더 기민하게 반응할 수 있습니다. 만약 윈도우 전체를 다시 그리는 커널 코드를 실행한다고 가정하면 그 시간이 얼마나 걸릴지... 그리고 그동안 인터럽트 처리가 안되면 어떻게 될지는 금방 상상이 되실겁니다. ^^;;;;;

 그런데 이게 Stack Switching이 발생하다보니, Kernel Level Stack을 Application들 끼리 공유하게 되더군요. 32bit 같은 경우는 Task 별로 TSS 영역이 존재해서 별도의 Kernel Stack을 할당해 줄 수 있었지만, 64Bit에서는 TSS가 Task에 종속적으로 존재하는 것이 아닙니다. 거의 Global하게 공통적으로 사용한다고 해도 될만큼 말입니다. ㅠㅠ

 하지만 커널 코드 수행 시, 인터럽트를 활성화하려면 태스크 별로 커널 스택을 별도로 가져야 하는데... 어떻게 할까 고민하다가 결국 Interrupt Service Routine에서 System Call용은 Kernel Stack에서 Application Stack으로 돌아가도록 했습니다. Stack Switching을 한번 더 한다는 이야기지요. 이렇게 하면 System Call 호출로 인해 Kernel Mode에 진입해 있지만 Stack은 Application의 Stack을 사용하기 때문에 커널 함수를 수행하는 도중 Task Switching이 발생해서 다른 Application이 Kernel로 진입해도 문제 없습니다.

 일단 대충 코드를 구현했는데... 오늘은 일찍 자는 날이라서 내일 테스트 해야겠군요. 별것 아닌 것 같은데... 해보니 별거(?)였다는... ㅠㅠ

 아직 내공이 많이 부족한가 봅니다. 크윽... 저의 애마(?) 마제스터치 키보드와 함께 계속 달려야겠군요.
 다들 그럼 좋은 밤 되세요. ;)

 드디어 응용프로그램을 외부에서 전송하여 실행하는데 성공했습니다. 외부 즉 윈도우와 가상 머신은 Serial Port로 연결했습니다. QEMU의 옵션 중에 가상 Serial Port를 열어주는 옵션이 있는데, 그것을 이용해서 가상머신에 Serial을 만들고 제가 만든 OS에서 그 Serial을 사용함으로써 통신에 성공했습니다. @0@)/~

 QEMU에서 TCP/IP로 Serial Port를 생성할 수 있는데, 아주 편하더군요. 덕분에 간단한 윈도우 소켓 프로그램으로 파일을 OS에 넘겨줄 수 있게 됬습니다. 아래는 제가 사용하는 QEMU 옵션인데, 맨 뒷줄 -serial 부터가 TCP/IP로 Serial Port를 생성해주는 옵션입니다. ^^



 아래는 QEMU에서 돌고 있는 제 OS에 파일 매니져가 응용프로그램 바이너리(elf64 파일 포맷)을 넘겨주는 화면입니다. OS에서 Serial로 열심히 데이터를 다운받아서 "."을  찍고있는 걸 볼 수 있습니다. ^^;;;;

 다운로드가 끝나면 OS에서 ELF64 파일 포맷인가 확인한 뒤, Relocation을 수행합니다. 그후 메모리를 할당받아 Relocation된 실행 파일을 복사하고 프로세스를 생성합니다. 원래는 ELF64 파일 포맷을 가공하려고 했습니다만, Relocation을 분석하는 과정에서 크게 복잡한 부분이 없어서 그냥 쓰기로 했습니다. ^^;;;

 아래는 여러 개의 Application을 OS에 업로드하여 실행한 화면입니다. 각자 자신의 Task ID를 표시하게 되어있습니다.

 어휴... 진짜 이것 저것 많이 했군요. 이제 내일은 GUI 쪽 System Call을 추가하고 좀 복잡한 Application을 로딩해서 정상적으로 동작하나 확인해 봐야겠습니다. >ㅁ<)-b

 이크~ 벌써 시간이 이렇게 됬군요. 그만 자야겠습니다. ㅎㅎ
 그럼 다들 좋은 밤 되세요 ;)

 제가 입사한지도 언 8개월이 지났습니다. 그 동안 많은 일이 있었지만, 오늘 좀 감동받은 일이 있어서 한자 적어봅니다. 다른게 아니라 회사에 같이 입사한 형이 드디어 퇴근 후에 자기 시간을 갖는 것에 대해서 긍정적으로 생각을 바꿨더군요. 이전에는 회사에 있는게 더 좋다고 생각했더랍니다. ^^;;;;

 저 같은 경우는 퇴근 후에 제 시간을 갖는 걸 좋아해서 왠만하면 집에 일찍가려고 했습니다. 하지만 같은 신입이니 저만 일찍 갈수도 없는 노릇이고... ㅠㅠ 덕분에 저는 형 대신에 좀 늦게가고 형은 저 대신에 좀 일찍가서, 제 의도와 달리 신입의 열심히하는 포스(?)가 나오더군요. ^^;;;; 사실 신입인 저희들이 남아있어봤자 하는 일 없이 교육듣는 게 전부였으니 남아있어도 별로 부담 없었지요.

 그러다 좋은 날은 가고, 드디어 저희도 폭풍에 같이 휘말리게 됬습니다. 가고 싶어도 갈 수 없고, 힘들어도 쉴 수 없는 상황이 오더군요. 그때쯤부터 형이 바뀌기 시작했습니다. 집에 일찍 가고 싶어하고, 회사에서 되도록이면 빨리 멀어지길 바랬습니다. ^^;;;;

 최근에는 형이 이제야 제 마음을 이해하겠다고... 주말에만 있을거라고 생각했던 "내 시간"이 평일에도 있는 걸 알았다고... 고맙다고 하는 것이 아니겠습니까? 솔찍히 깜짝 놀랐습니다. @0@)-b 그리고 불과 몇개월만에 사람이 이렇게 변할수도 있구나 하는 생각을 했고, 형이 드디어 자기 시간이 얼마나 좋은 것인지를 알게되서 살짝 기뻤습니다. 자기 시간이 생기면 휴식도 취하고 자기 개발도 할 수 있으니 얼마나 좋습니까? ^^)/~

 그런데 요즘 같이 입사한 동기나 후배들은 일이 너무 힘들어서 집에가서 잠만자더군요. ㅠㅠ 솔찍히 많이 안타깝습니다. 회사에서 여유를 너무 안주는 게 아닌가 하는 생각도 들고... 프로그래머에게 꼭 필요한게 자기 개발인데 그런 부분을 보장해주지 못하다니... 이건 회사 입장에서도 손해인 것 같습니다. 이래서 어디 롱런하겠습니까? ㅡ_ㅡa..

 엇... 이야기하다가 말이 좀 빗나갔는데... ^^;; 여튼 일찍 퇴근하는 건 좋은 겁니다. 요즘은 형이 일찍가자고 하는 덕분에 업무시간에 일을 최대한 빨리 끝내려고 합니다. ㅎㅎ 예전 같으면 어차피 저녁에 갈꺼니까 일을 질질 끄는 경향이 좀 있었는데... 일찍 가려니 어쩔 수 없더군요. ㅎㅎ 회사 입장에서도 야근비 안나가니까 더 좋은 것 같습니다.

 앞으로도 계속 일찍 퇴근하려고 노력해야겠습니다. 칼퇴근 만쉐~!!!!
 회사는 직원들의 칼퇴근을 보장하라~!!!!





 

 이제 OS를 만드는 작업이 거의 막판까지 왔습니다. 커널에서는 이미 System Call 처리를 위한 준비를 끝낸 상태이며, 이제 응용프로그램을 적절히 로드해서 실행하는 것만 남았습니다. ^^;;; 그동안 작업을 주로 윈도우 환경에서 했기때문에 PE 파일 포맷을 주로 다뤘습니다(PE 파일 포맷에 대한 내용은 http://kkamagui.tistory.com/search/PE%20%ED%8C%8C%EC%9D%BC 을 참고하세요).

 이번에 ELF 파일 포맷 쪽을 다루는 김에 문서를 좀 남겨둘려고 허접하지만 문서 작업을 같이 했더니, 이해하는데 훨씬 도움이 되더군요. 물론 아는 내용을 정리하는 작업이 좀 지루하기는 하지만, 시간이 지나면 다 잊어먹으니 나중을 대비해서라도 정리하는 게 좋을 것 같더라구요. ㅎㅎ

 정리를 죽 하다보니, 머리로만 이해하고 있던 내용 중에 잘못된 것도 찾을 수 있었고, 확실히 보지 않으면 정리를 할 수 없으니 문서를 세세히 찾아볼 수 있었습니다. ^^;;; 어제 늦게 정리된 내용을 바탕으로 ELF64 Relocator(가칭)을 만들었는데, 나름대로 잘 동작하더군요. :)

 ELF64 Relocator는 Relocatable 파일 형식으로 생성된 ELF64 파일을 Relocation을 수행해서 마치 Executable 파일 형식으로 생성된 것 처럼 만들어주는 프로그램입니다. 만약 문서를 제대로 이해했다면 Relocatable 파일 형식으로 나온 것을 Relocation 시킨 결과나 Executable 파일 형식으로 만든 결과가 같아야 합니다. 간단한 테스트 프로그램으로 테스트 해본 결과 디스어셈블리한 결과가 똑같이 나왔습니다. >ㅁ<)-b

 아아~ 이제 남은 것은 OS에서 ELF64 형식을 그대로 쓰느냐, 아니면 별도의 가공을 통해 새로운 파일 포맷을 만드느냐인데... 사실 가장 좋은 방법은 ELF64의 Relocatable 파일 형식을 그대로 쓰는 겁니다. 이렇게되면 별 다른 수정없이 윈도우나 리눅스 계열에서 빌드된 ELF64 파일을 그대로 실행할 수 있는 장점이 있습니다. 하지만 단점은 커널에 들어있는 실행파일 로더(Loader)가 복잡해진다는 것이지요. ㅠㅠ

 새로운 파일 포맷을 만드는 방법은 커널에 있는 로더를 간단히 할 수 있는 장점이 있습니다만, 파일 포맷을 변환하는 단계를 거쳐야되서 빌드 시에 단계가 하나 더 추가되는 단점이 있습니다. 파일 포맷 변환 프로그램도 작성해야하구요. ㅎㅎ

 이거 어느 것을 선택하는 게 옳은 건지 판단을 내리기가 좀 힘들군요. 빨리 이걸 결정해야 실행파일을 돌려볼 수 있을텐데... ㅠㅠ 어휴... 고민입니다. ㅠㅠ