kkamagui의 작업실

<현재 진행 중인 GUI 시스템의 화면> 

추석 연휴 때부터 이것 저것 일이 많아서 미친 듯이 달려왔더니 이제야 블로그에 한자 적어 올립니다. ㅠㅠ 아흑... 요즘 회사에서도 신경 쓸게 많다 보니 점점 작업시간이 줄어들어서 이러다가 큰일(?)나게 생겼네요 ㅠㅠ. 그래도 작업은 해야 하는지라 아침에 좀 무리해서 진행하고 있습니다(이러다 쓰러지는 게 아닌가 모르겠군요. 쿨럭..;;;)

그동안 아주 쉬운 알고리즘을 사용해서 GUI 시스템 작업을 했는데... 이제야 어느 정도 모양이 나와서 올려봅니다. ^^;;; 이제 조금만 더 있으면 바이너리 정도는 공개할 수 있는 퀄러티가 나오겠군요. 일단 윈도우 생성, 닫기, 선택/선택 해제, 이동 정도 구현된 상태입니다. 크기 변경이랑 화면을 좀더 효율적으로 그리는 부분은 좀더 진행되어야 할 수 있을 것 같군요. 아래는 지금까지 구현된 MINT64 OS의 구동 화면입니다. ;)

어휴... 이제 또 달려봐야겠네요. ㅠㅠ 다음 포스팅은 언제가 될지 모르겠지만... 조만간(?) 다시 하나 올리겠습니다.

ps) 어휴... 이것 참... 언능 해야 될 텐데... 큰일이군요. ㅠㅠ

지난 주에 아우~ 새벽형 인간으로 바꾼지 일주일쯤 지났습니다. 그리고 아침에 꾸준히 작업한 결과 MINT64 OS에 새로운 기능을 추가할 수 있었습니다. ;) 바로 클리핑(Clipping) 기능입니다.

클리핑 기능은 화면에 표시되지 않는 영역을 잘라 내어 이미지가 요상(?)하게 출력되는 것을 막는 작업입니다. 요상하게 표시되는 게 어떤 건지는 아래 두 화면을 비교해 보면 금방 알 수 있습니다. 위의 그림과 아래 그림을 비교해 보면 클리핑 처리를 하지 않았을 때는 화면 영역을 벗어난 나머지 영역이 그 반대편에 표시됩니다.

<클리핑 전 화면>

<클리핑 후 화면>

클리핑 처리가 필요한 이유는 비디오 메모리가 연속된 하나의 덩어리기 때문입니다. 즉, 우리가 화면에서 보는 라인 단위로 딱딱 구분되어 있는 것이 아니라, 라인들이 순서대로 주욱 연결되어 하나의 메모리 공간을 형성하고 있습니다. 그래서 윗 라인의 끝부분에 윈도우를 출력하면 그 다음 라인까지 영향을 받습니다. 클리핑 처리는 보이지 않는 부분은 그리지 않음으로써 이러한 문제를 해결하는 기법입니다. ^^;;;;

사실 어렵게 하려면 한없이 어렵게 할 수 있고, 속도를 좀 포기하면 한없이 쉽게 할 수 있는 것이 클리핑 처리인데... 저는 쉬운 방법을 택했습니다(어떻게 했는지는 “비밀” 입니다. ㅎㅎ 나중에 공개할께요 ^^;;).

에휴~ 이제 슬슬 마우스를 추가해야겠군요. 마우스가 없으니 원... 그냥 랜덤하게 출력하는 것 말고는 별로 할 게 없네요. 급히 하나 추가해 봐야겠습니다. ㅎㅎ 그럼 다들 좋은 주말 되시길 ;)

다음주면 GUI 시스템 작업을 해야 해서, 오늘 디자이너 준에게 부탁해서 프로토타입 이미지를 받았습니다. ㅎㅎ 바탕화면과 윈도우 프레임을 조합하고 보니 예전 것보다 훨씬 깔끔하네요. ㅠㅠ 어흑... 이때까지 GUI 시스템을 만들면서 윈도우 색깔이나 모양에 신경을 쓴 적이 없었는데... 시간을 좀 들이고 나니까 훨씬 멋지군요. ㅠㅠ

<MINT64 OS의 GUI 시스템 프로토타입>

<예전에 만들었던 GUI 시스템의 프로토타입>

녹색이 생각보다 촌스러운 색(?)이어서 조금만 잘못 써도 감(?)이 확 떨어져 보이던데... 멋지게 작업해 준 디자이너 준에게 감사의 말씀을 드립니다(준영아 사랑해~!! ㅋㅋ). 디자이너 준의 노력에 보답하려면 열심히 그대로 옮겨야겠네요. ㅎㅎ

아우~ 벌써 시간이 이렇게... ㅠㅠ 혹시 보시고 뭔가 부족하다고 생각되는 부분이 있다면 댓글로 제보(?) 부탁 드립니다. ;) 아직 2주 정도 시간이 있으니까 나중에 상의해서 반영하겠습니다. ;)

태스크 부하 분산(Task Load Balancing)을 구현하는 중인데... PIT 컨트롤러의 인터럽트에서 스케줄러의 상태를 보고 태스크가 적은 곳에 집어 넣는 방법을 사용했습니다. 그런데 ㅡ_ㅡa... 이게 문제가 있네요. 난데없이 집어 넣은 스케줄러에서 실행되는 것이 아니라 다른 스케줄러에서 튀어나오질 않나... 같이 스핀락을 획득하는 부분이 없는데 데드락이 발생하지 않나... ㅡ_ㅡa... 그것 때문에 어제 밤 9시경부터 오늘 아침 8시까지 디버깅했습니다. 결과는 GG ㅠㅠ

디버깅을 미친 듯이 한 덕분에 오후 3시쯤 느즈막하게 일어났군요. 당췌... 이게 무슨 일인지... 다 해 놓고 막판에 테스트할 때 이런 문제가 나오면... 어흑... ㅠㅠ 그나마 GUI로 넘어가기 전에 발견했기에 망정이니... 아니면 큰일날 뻔 했습니다.

어휴 진짜... 증상은 있는데... 원인을 정확히 알 수가 없네요. ㅠㅠ 스핀락에 문제가 있는 것도 아니고... 코어가 많아서 그런 현상이 발생한다고 보기에는 뭔가 미심적인 부분이 있습니다(16개 코어 + 800개 태스크로 테스트를 하고 있답니다. ㅎㅎ). 그래서 방향을 선회해야겠는데... 시간이 좀 촉박한지라 고민을 계속 하고 있습니다. 오늘 안에 결과가 나오면 좋겠는데... 과연 잘 될지 모르겠네요. ^^;;;;

일단 또 작업을 시작해야겠습니다. ㅎㅎ 저녁쯤에는 글 하나를 더 쓸 수 있으면 좋겠군요 ㅠㅠ)-b

이번 주는 휴가도 있었고 해서 금방 주말이 오더군요. 그래서 그런지 주말이 아주 짧은 것 같습니다. ㅠㅠ 뭐 어제가 금요일인 것 같은데... 벌써 일요일 오후군요. ㅠㅠ(이 짧은 문장 치는데 ㅠㅠ가 몇 번이나 들어갔는지... 어흑... ㅠㅠ)

“회사일 + 프로그램 개발 + 드라이버 업데이트”이 세 가지가 한꺼번에 들이 닥치는 바람에 한 주가 정말 정신 없이 지나갔습니다. 하루는 해 뜨는 거 보고 바로 출근하는 기염을 토하기도 했지요. ㅠㅠ 어흑... 그래서 주말은 내내 잠만 잔 것 같습니다(헉... 그래서 주말이 짧은 건가...^^;;)

아무리 피곤해도 MINT64 OS는 진행해야 하는지라... 졸린 눈을 비비며 작업한 결과~!!! 일단 대칭 I/O 모드(Symmetric I/O Mode)로 전환은 시켰습니다. 대칭 I/O 모드가 무엇인고 하니, 멀티 프로세서나 멀티코어 프로세서를 사용할 때 여러 코어에 인터럽트를 전달하는 방식을 말합니다. 이렇게 하려면 PIC 컨트롤러가 아닌 I/O APIC와 로컬 APIC를 사용해서 인터럽트를 처리해야 합니다. ㅎㅎ 이제 다른 OS들처럼 인터럽트 로드 밸런싱(Interrupt Load Balancing) 정도는 할 수 있는 거죠. ;)

<대칭 I/O 모드(Symmetric I/O Mode)> 

예전에 프로토타입을 만들 때는 인터럽트 로드 밸런싱 처리가 상당히 복잡했는데... 이번에는 아주 간단하게 끝냈습니다. ㅡ_ㅡa.. 역시 두어번은 짜봐야 제대로 된 로직이 나오는가 봅니다(사실 제가 허접해서... ㅡ_ㅡa...). 자세한 방법은 인터럽트 로드 밸런싱까지 처리되면 Milestone에 올리겠습니다. ㅎㅎ

아흐~ 오늘은 집 정리도 하기로 했는데... 시간이 좀 촉박할 것 같기도 하군요. 일단 또 한번 달려 봐야겠습니다. 다들 남은 주말 마무리 잘하세요 ;)

ps) 그냥 아무것도 안올리기가 뭐 해서, 대칭 I/O 모드로 전환해서 하드 디스크를 읽은 화면을 올립니다. ㅡ_ㅡa...

이번 포스팅은 거의 2주 만에 하는 것 같군요. ;) 이번에는 파일 시스템을 구현하다 보니 양이 많아서 이제야 겨우 끝났습니다. 일단 인증샷부터 보시죠. ;)

<MINT 파일 시스템을 구동한 동영상>

MINT 파일 시스템은 FAT 파일 시스템처럼 클러스터를 링크로 연결하는 형태로 되어 있습니다. 사실 FAT 파일 시스템을 쓸까도 고민했었는데, FAT 파일 시스템을 정리하고 구현하려면 양이 많아질 것 같고, 그렇다고 정리를 안 할 수는 없으니 그냥 간단한 파일 시스템을 만드는 것으로 했습니다. 그래서 나온 것이 MINT 파일 시스템인데 아래와 같은 구조로 만들었습니다.

<MINT 파일 시스템의 전체적인 구조>

척 봐도 FAT 파일 시스템과 아주 유사하다는 것을 알 수 있습니다. 디렉터리 엔트리 구조도 아주 단순합니다. 디렉터리 엔트리는 32 byte이며 파일 이름 24 byte와 파일 크기 4 byte, 그리고 파일 시작 클러스터 4 byte가 전부입니다. 클러스터 크기가 4Kbyte이므로 한 클러스터에 최대 128개의 파일을 생성할 수 있습니다.

<디렉터리 엔트리(Directory Entry)의 형식과 루트 디렉터리(Root Directory)의 구조>

이쯤되면 FAT 파일 시스템을 구현하는 게 더 낫지 않냐고 생각할지도 모르겠지만... MINT 파일 시스템은 극단(?)의 제약 사항을 걸어서 구현할 코드의 량을 대폭 줄였습니다. 그 제약 사항이 뭐야 하면...

그렇습니다~!!! 서브 디렉터리를 제공하지 않고, 루트 디렉터리의 크기를 고정함으로써 경로(Path)처리나 디렉터리 처리에 관련된 코드를 대폭 줄인 것입니다. 실제로 예전에 FAT 파일 시스템을 구현했을 때와 비교한다면, 1/3 수준입니다. 물론 아쉬운 부분이 있긴 하지만... MINT64 OS처럼 간단한 OS에서 쓰기에는 충분한 것 같습니다. 어렵게 구현하는 것 보다 일단 구현하기 편하고 잘 돌면 되지요. ;)

구현할 양이 작아진 덕분에 C 언어 표준 입출력 함수, 즉 fopen(), fread(), fwrite(), fclose(), fseek(), opendir(), readdir(), rewindir(), closedir() 함수도 구현할 수 있었습니다. 마치 윈도우나 리눅스에서 콘솔 프로그램을 작성하듯이 MINT64 OS에서도 가능하다는 이야기지요. ㅎㅎ 실제로 아래는 위의 동영상에서 파일을 쓰고 읽는데 사용된 코드입니다.

아아~ 이제 파일 시스템에 캐시(Cache)를 넣고 램 디스크를 추가해야겠군요. 원래 이번 주 월요일에 시작해야 했는데 파일 시스템을 만드는 것이 늦어져서 이제야 시작합니다. ㅠㅠ 아흑... 또 주말을 반납해야 한다는... ㅠㅠ 열심히 만들어서 곧 Milestone을 하나 올리겠습니다. ;)

그럼 다들 즐거운 주말 되세요. ;)

휴가를 다 반납하고 집에 틀어박혀 작업만 한 결과, 파일 시스템 기본 API를 만들었습니다. 물론 파일 시스템도 허접하게 하나 만들고 말이지요. 그런데 만든 API가 워낙 허접하다 보니 빈 파일 하나를 생성하고 삭제하는 기능 말고는 되는 게 없네요. ㅠㅠ

아흑... 이래서는 안되겠다 싶어서 표준 입출력 함수처럼 open, read, write, close, opendir 등등을 만들고 있습니다. 오늘이 벌써 수요일이니까 이번 주까지 할 수 있을지 모르겠지만, 일단 최선을 다 해야 할 듯 하군요. 에혀... 점점 갈 길은 아직 먼데 체력은 점점 떨어지고 있어서 큰일 났습니다.

무슨 수를 쓰긴 써야 할 때인 것 같군요. ㅎㅎ 일단 좀 더 달려 보고 안되면 특단의 조치(?)를 내려야겠습니다. 홧팅~!!!

ps) 그래도 Milestone인데 아무것도 없으면 허전할 듯 해서, 하드 디스크를 MINT 파일 시스템으로 포맷하고 나온 정보를 표시하는 화면을 올립니다. 어흑... 이런거나 올려야 되다니... 정말 한 게 없군요. ㅠㅠ

거의 이틀 간의 삽질 끝에 부팅에 성공했습니다. ;) 물론 한번에 성공한 건 아니고, 여러 문제가 있었습니다. ^^;;;; 것 참... 버그가 한 두 개가 아니더군요.

첫 번째 버그는 IDE 하드를 체크하는 루틴에 있었습니다. 가상 PC에서는 IDE를 사용한다는 가정하에 코드를 작성했는데, 실제 PC는 SATA였기 때문에 동작하지 않더군요. ^^;;; 원래는 타이머를 체크하면서 검사하게 되어 있었는데 인터럽트 불가 루틴이 앞에 있어서 결국 타이머가 이벤트가 발생하지 않았고 무한 루프를 돌았다는... ㅠㅠ

두 번째 버그는 대충 만든 동적 메모리 할당 루틴 때문이었습니다. 이상하게 어디서 int 타입으로 계산했는지 2GB 이상의 어드레스의 메모리를 할당 받으면 sign extension이 일어나서 Unsigned Long 타입으로 받았을 때 상위 32bit가 모두 0x0F로 설정됐습니다. ㅠㅠ  가상 PC에는 메모리를 최대 64MB로 설정해 놨기 때문에, 발견되지 않았더군요. 크윽...

세 번째는 MTRR 레지스터를 잘 못 설정해서 생긴 문제였습니다. ㅠㅠ 어설프게 배웠더니(?) 홀수 MB 메모리는 캐시를 사용하도록 설정하고 짝수 MB는 캐시를 사용 안 하도록 설정했더군요. 그 덕분에 굉장히 느린 GUI 화면을 볼 수 있었습니다. ㅡ_ㅡa... 어찌나 느리던지... RDTSC를 통해 CPU 속도도 재보고, 프로파일러를 만들어서 화면 업데이트 속도도 재 봤는데... 헉... 초당 3 프레임 정도 나왔습니다. 하도 이상해서 램, 비디오 램 두 영역을 잡아서 1024 * 768 * 2 Byte를 동일한 함수에서 채워 봤습니다. 얼래... 램이랑 비디오 램이랑 둘 다 비슷하더군요. ㅡ_ㅡa... 램 영역은 캐시를 활성화 하도록 했기 때문에 원래대로라면 램이 더 빨라야 하는데 말이죠. ^^;;;; 결국 잘못 셋팅해서... ㅠㅠ

이런 자잘한(?) 문제를 다 해결하고 나서야, 광속(?)으로 동작하는 MINT64 OS를 볼 수 있었습니다. 코드 두줄 바꿨을 뿐인데 정말 빠르더군요. ㅠㅠ)-b 크윽... 초당 3프레임 나올 때는 진짜 띵~ 하던데...ㅠㅠ 기념으로 사진을 찍어서 올립니다. ㅎㅎ 동영상을 찍고 싶었지만 카메라가 꾸져서... 다음에 디카를 사면 한번 찍어 올리겠습니다. ㅎㅎ

이제야 다시 정리(?)하는데 집중할 수 있겠군요. 덕분에 주말의 2/3을 날렸네요. ㅎㅎ 그래도 기분은 좋습니다. ;) 앗싸 MINT64 OS 만세~!!!

ps) 이번에 좁은 책상을 버리고 퍼즐 형태의 사무용 책상으로 바꿨더니 작업 능률이 200%는 올라간 것 같습니다. 역시 작업 환경은 무조건 좋고 봐야 합니다. ;) 그지? 후배야? ㅋㅋ