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


아래의 첫 번째 화면은 이제 만들 GUI 시스템의 프로토타입이고 두 번째 화면은 MINT64 OS 검증용으로 잠시 만들었던 OS의 GUI 시스템 화면입니다. MINT64 OS라는 이름에 맞추어 이번에는 녹색 계열로 배색해 봤습니다.

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


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

 

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


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


ps) 참고로 이미지의 저작권은 디자이너 준에게 있습니다. ㅠㅠ 무단으로 도용하면 미워할꺼에요 ㅠㅠ

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

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

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

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

근 10일에 걸친 대장정이 끝났습니다. ㅠㅠ)-b 중간에 코드를 한번 잘못짜서 디버깅을 다시 하는 사태도 발생했지만, 결국 끝났습니다. ㅠㅠ 잠결에 코딩을 했더니만 알 수 없는 코드들이 중간 중간에 잔뜩 들어가 있더군요. ㅠㅠ 어흑 ㅠㅠ

코어 16개를 모두 활성화한 뒤에 대칭 I/O 모드(Symmetric I/O Mode)로 전환하여 인터럽트 처리 횟수가 전체적으로 10 이상 차이가 나면 인터럽트를 분산하도록 했습니다. 뭐, 매번 돌리면서 인터럽트를 분산시킬 수도 있지만 약간 오바인 것 같아서... ^^;;;;

아래는 인증 샷입니다. :) 코어 16개를 활성화하기 전에 인터럽트 처리 횟수를 출력하고, 16개를 활성화한 후 다시 출력했습니다. 그리고 마지막으로 인터럽트 부하 분산 기능을 활성화해서 키보드를 난타한 다음 최종적으로 처리된 횟수를 출력하도록 했습니다.

 


에혀~ 이제 스케줄러를 코어마다 추가하고 태스크 부하 분산(Task Load Balancing)만 처리하면 끝이군요. ;) 대망의 GUI로 넘어갈 수 있을 것 같습니다. ㅎㅎ 정리하면서 하느라 여기까지 오는데 꽤나 걸렸는데... 이제 좀 속도가 다시 붙을 것 같군요. ;) GUI는 지금까지 했던 것 보다는 알고리즘이 간단하니까 말이죠 ;)

에궁~ 오늘은 일찍 잘려고 했는데... 결국 또 이렇게 되는군요. ㅠㅠ 언능 누워야 겠습니다. ㅎㅎ 다들 좋은 밤 되세요 ;)


ps) 인터럽트 부하 분산 기능을 추가하긴 했는데... 시리얼 포트를 폴링 방식으로 사용하다보니 그다지 인터럽트 부하가 발생하지 않더군요. ㅡ_ㅡa... 사실 크게 이득이 없는 것 같습니다. 나중에 기가바이트 이더넷이나 추가하면 효과를 좀 볼지... ㅎㅎ :)

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

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

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

image

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

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

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

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

image

헥헥... 이번에는 거의 3주 만에 블로그에 글을 올리네요.  ㅠㅠ 점점 글 올리는 주기가 길어지는 걸 보니 조만간 폐허(?)가 되는 게 아닌가 걱정되는군요. ㅠㅠ 정말 블로그에 글 올릴 시간도 없이 열심히 작업했는데, 이제야 겨우 끝났습니다. 사실 코딩하는 데는 이틀 밖에 안 걸렸지만 내용 정리하는데 12일 정도가 걸렸군요. ㅡ_ㅡa... 회사를 다니고 있으니 야간에 작업을 해야 하는데, 그래서 더 어려운 것 같습니다. (이거 원... 잘하면 회사도 때려 치겠군요. 쿨럭..;;;;)


이번에 추가된 기능은 프로세서 내에 잠자고 있는 나머지 코어를 깨우는 일이었습니다. 보통 부팅을 시작하면 BIOS가 코어 중에서 하나만 선택해서 BSP(Bootstrap Processor)로 만든 후 부팅을 시키고, 나머지는 AP(Application Processor)로 만들어 대기시킵니다. BSP는 부팅이 끝나면 MP Configuration Table 같은 걸 읽어서 잠자고 있는 AP의 수를 계산한 뒤 나머지를 깨워서 일을 시키는 것이지요.


MP Configuration Table을 분석하는 작업은 지난 번에 했으니, 이번에는 이 정보를 바탕으로 AP를 활성화했습니다. 아래 그림은 총 16개의 코어를 활성화하여 각자가 메시지를 출력하게 한 것입니다.


 <총 16개의 프로세서(BSP 1개, AP 15개)가 동시에 동작하는 화면> 


아아~ 정말 작업하는 게 쉽지 않군요. 별다른 동기 부여 없이도 꾸준히 하는 스타일인데... 요즘은 살짝 지치는 느낌입니다. 아무래도 배보다 배꼽(?)이 더 큰 상황 때문이 아닐까 생각하는데... 앞으로 MileStone 2개 정도만 더 올리면 GUI라서 꾹 참고 진행하고 있습니다. ;)


에궁... 다음 MileStone은 BSP와 AP가 동시에 인터럽트 처리를 하는 것이 될 것 같습니다. 이것만 지나가면 AP에도 스케줄러를 붙여 멀티 태스킹 시킬 수 있으니... 거의 끝난 것이죠. ;) 아유~ 지겹네요. ㅠㅠ 그래도 열심히 해야지... 어쩌겠습니다. 어흑...


장마 전선이 올라왔다던데... 다들 비 피해 주의하시고 건강 잘 챙기세요 ;)


ps) 곧 GUI로 들어간다니 여자 친구가 MINT64 OS에서 쓸 바탕 화면을 디자인해 줬습니다.이 중에 하나를 택해야 할 것 같은데... 어떤 것이 좋을까요? ;)

 

 

드디어 긴긴 Single Core Processor 관련 부분을 마무리하고 Multicore Processor쪽으로 들어갔습니다. 이번에는 가장 기본이 되는  MP Configuration Table을 분석하는 기능을 추가했습니다. MP Configuration Table은 BIOS에서 만드는 것으로, 코어의 개수와 인터럽트 연결에 관련된 포괄적인 정보를 담고 있습니다. ;) 아래 그림을 보는 게 더 빠를 듯...

MP Configuration Table을 분석하는 이유는 실제 Core의 개수를 찾는 것과 나중에 인터럽트를 모든 Core로 전달하기 위해서입니다. BIOS는 부팅 과정에서 부팅을 담당하는 프로세서인 BSP(Bootstrap Processor)로 PIC 컨트롤러의 인터럽트 라인을 연결하므로, AP(Application Processor)를 깨운다 해도 PIC 컨트롤러의 인터럽트는 전달되지 않습니다. ;) 전달된다 하더라도 PIC 컨트롤러는 Multicore Processor를 지원할 능력이 없으므로 오동작하겠지요. ;)

따라서 Local APIC와 I/O APIC를 이용해서 모든 Core로 전달되도록 설정해야 하는데, 이때 MP Configuration Table에 저장된 정보가 아주 중요한 역할을 합니다. 실제 메인보드 제조사는 인터럽트를 어떻게 연결했는지를 알고 있으므로, BIOS에 그 정보를 저장해 둡니다. 이 정보가 MP Configuration Table에 들어 있는 것입니다. 만약 MP Configuration Table을 사용하지 않는다면... ㅎㄷㄷ... 생각만 해도 이건... ㅠㅠ

여튼~!!! 분석하는 게 끝났으니 이제 깨워서 일 시키는(?) 일만 남았군요. ㅎㅎ 아우 진짜 죽겠습니다. 이것만 끝나면 GUI로 바로 날아갈 텐데... ㅠㅠ  좀이 쑤셔 죽겠군요. ㅎㅎ 다음 작업도 끝나는 대로 인증 샷을 올리겠습니다. 다음 인증 샷에는 쌍둥이(?)가 열심히 일을 하는 화면이 나오겠군요. ;)

그럼 다들 좋은 저녁 되세요 ;)

ps) 아래는 QEMU의 MP Configuration Table의 내용입니다. 실제 PC와는 좀 다른 모습이군요. ;)



이번에도 상당히 오랫동안 작업했습니다. 요즘은 귀차니즘이 도져서 가만히 않아서 작업하는 게 힘듭니다. 그래서 약간 진도도 처지고 의욕이 살살 꺼지고 있습니다. 그래도 갈 길이 멀기에 끙끙거리면서 작업해서 겨우 붙였군요. ;)


일단 말이 필요 없으니, 직접 한번 보시죠. ;) QEMU에서 실행해서 새 그림이 그려 진 텍스트 파일을 수신한 후, 그것을 다시 화면에 표시한 동영상입니다. 화면을 캡쳐한 것을 올려도 되지만, 동영상이 좀 더 액티브(??)하니 동영상으로 올렸습니다.


<동영상 파일을 변환하니 깨져서 그대로 올렸더니 파이어폭스에서는 제대로 안보이는 문제가 있네요. ㅠㅠ>

https://t1.daumcdn.net/cfile/tistory/13153C1B4A31337702 를 클릭하시면 다운로드 받아서 볼 수 있습니다.



파일 시스템이 생기니 이런 재미난 일도 할 수 있군요. ㅎㅎ 너무 신납니다. ;) 그러고 보니 OS의 기본 기능은 대부분이 구현되었군요. 이제 남은 건 멀티 코어를 활성화하는 부분이랑 GUI 정도인 것 같은데... 다음 이번 달과 다음 달은 꽤나 고생하겠다는 생각이 드는군요. ㅠㅠ 어흑 언능 작업해서 재미난 GUI로 가고 싶어요. ㅠㅠ 그럴려면 또 열심히 달려야겠군요. 어흑...

그러기 전에 오늘은 일단 좀 쉬어야겠습니다. 피곤에 너무 찌들어서 한참을 골골거렸다는 ㅋㅋ 그럼 다들 좋은 밤 되세요. ;)


ps) 다음은 MINT64 OS에서 전송한 ASCII Art 파일을 표시한 것을 캡쳐한 화면입니다. 예전에 쓰던 마스코트인 까마귀입니다. 어때요? 비슷하죠? ㅎㅎ


이번 포스팅은 거의 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을 하나 올리겠습니다. ;)

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

<QEMU에 등록된 20MB짜리 하드 디스크의 정보를 읽은 화면>


읏차~ 예상 외에 변수가 생겨서 생각보다 조금 더 걸렸군요. ㅠㅠ 예전에 짰던 코드에 또 버그가 나와서 고칠까 말까 고민하다 보니 시간이 꽤 지났습니다. ㅠㅠ 수정하는 게 당연한데 왜 고민한 건지 잘 모르겠네요. (잠결에 그랬나? ㅡ_ㅡa..)

<LBA 0 어드레스에 2 섹터를 쓴 화면>

일단 간단히 읽고 쓰고를 반복해 본 결과 별 문제가 없는 것 같으니, 파일 시스템으로 넘어가야겠습니다. 파일 시스템은 FAT 파일 시스템을 아주 가볍게 개량해서 만들 생각입니다. 글은 이렇게 썼지만 사실 이미 작년 이맘때쯤에 만들었습니다. ㅡ_ㅡa;;; 아주 허접하지만 FAT 파일 시스템 드라이버를 만드는 것보다 일도 작고(과연??) 나름대로 쓸 만해서 이걸로 가기로 했습니다. 뭐 이름은 MINT64 Simple File System으로 해서 MSFS....가 아니라 MINTFS로 해야겠군요. ㅡ_ㅡa... 어디서 많이 본 듯한 이름이... 쿨럭..;;;


아아~ 또 바쁘게 하나 해야겠습니다. ㅎㅎ 이번 주말에 파일 시스템 스크린샷을 올릴 수 있으면 좋을 텐데.... ^^;;; 일단 열심히~!!! 그럼 다들 좋은 밤 되세요 ;)


하드 디스크 디바이스 드라이버 관련 링크는 아래를 참고하세요

http://www.nondot.org/sabre/os/articles/DiskandDiscDrives/

와아~ 드디어 또 기다리던 주말이군요. ㅠㅠ)-b 이번 주도 컨디션 난조로 거의 버리다시피 해서 주말에 작업을 많이 해야 하지만... 고향에 가야 돼서 이번 주도 좀 어렵겠군요. ㅠㅠ 요즘 날씨가 이상해서 그런지 영 컨디션이 좋지 않습니다. 머리가 마치 굳어 있는 듯한 느낌이랄까요? 귀도 머엉~ 하게 울리고... ㅠㅠ

그냥 다 때려치우고 잠시 쉬고 싶은 마음도 있지만... 영 쉽지 않네요. 지금 쉬면 뒷탈이 생길 것 같아서 어떻게든 작업을 하려고 노력 중입니다.(누가 상 안주나요? ㅎㅎ) 열심히 해서 이번 주도 Milestone 하나를 올려야 할 텐데... 벌써 걱정이 태산이군요. ㅠㅠ

또 끄적 끄적거려 봐야겠습니다. ㅠㅠ 다들 즐거운 주말 되세요 ㅠㅠ)/~

<64MB 영역 중에서 17MB를 커널 영역으로 사용하고 나머지 47MB를 동적 메모리 영역으로 할당한 화면>

아아~ 정말 이번 내용은 길고 지루했습니다. ㅡ_ㅡa... 내용 정리하는데 거의 9일이 걸렸고, 쓴 내용을 검토하는데 거의 5일이 걸렸습니다. ㅠㅠ 동적 메모리 할당과 해제에 대한 내용이다 보니 다른 스텝보다 좀 아니 훨씬 많더군요. 진짜 죽는 줄 알았습니다. ㅠㅠ


그래도 온몸을 배배 꼬아 가며 정리한 보람이 있는지 마무리하긴 했습니다. ;) 그리고 무시무시한 버그도 녀석도 하나 잡았지요. ㅎㅎ 지난번에도 캐시를 잘못 설정해서 GUI의 속도가 무진장 느린 문제가 있었는데, 이번에도 캐시 때문에 메모리에 접근하는 시간이 무지 걸리는 문제가 발생했습니다(이전에 발생한 캐시 문제는 http://kkamagui.tistory.com/608 에서 볼 수 있습니다).  지난번에 당한 게 있어서 금방 해결은 했는데... 왠지 좀 씁쓸하더군요. 약 10 챕터 정도를 거슬러 올라가서 다 수정해야 했기 때문입니다. ㅠㅠ 아흑... 몇십 분을 삽질하려니 죽을 맛이었습니다. 그래도 일찍 찾아서 다행이네요. ^^;;;; 저쪽 뒤에서 찾았다면 아마 기절했을 듯합니다. ㅎㅎ 이만하길 다행이랄까요?


동적 메모리를 처리하는 알고리즘으로는 제가 즐겨 쓰는(?) 버디 블럭 알고리즘(Buddy Block Algorithm)을 썼습니다. 버디 블럭 코드만 4번째 구현하는데, 이번이 그나마 제일 깔끔한 것 같네요. 나름대로 튜닝도 해서 속도도 만족스럽게 나오고... ^^;;; 혼자 쓸게 아니라서 신경 좀 썼습니다. MINT64 OS에서 구현한 방법은 나중에(?) 공개하겠습니다.


버디 블럭 알고리즘이 궁금하신 분은 http://kkamagui.tistory.com/20 를 참고하기 바랍니다(예전에 만든 자료라서 좀 부실하지만 어떤 원리로 동작하는지 확인하는 용도로는 괜찮을 듯 하군요. ^^a... ).


에혀~ 그러고 보니 또 한 주가 사라졌군요. ㅠㅠ 이러면 안 되는데... 언능 작업 들어가서 부족한 시간을 보충해야겠습니다. 그럼 다들 즐거운 주말 되세요. ;)

근 3주만에 Milestone이군요. ;) 3주동안 감기 몸살에 멤버십 후배들 호출에... 뭐 기타 등등이 섞여서 작업이 좀 더뎠습니다. 덕분에 2주 동안 해야할 분량을 3주나 되서야 겨우 끝냈군요. ㅠㅠ 아흑... 피 같은 한주가 그냥 사라져 버렸네요. ㅠㅠ

3주동안 MINT64 OS에 많은 변화가 있었습니다. 첫 번째는 멀티 태스킹과 멀티 스레딩 기능이 추가되었다는 것이고 두 번째는 실수 연산 기능이 추가되었다는 것입니다. 이 두가지 기능이 추가됨으로써, 태스크 관리쪽이 거의 마무리 되었네요. ㅎㅎ

역시 기념으로 스크린 샷을 찍어 올립니다. 그리고 이번에는 좀 특별하게 동영상도 찍었습니다. ;) 왠지 정지해 있는 화면만으로는 뭐가 어떻게 돌아가는지 확인하기 힘들 것 같아서요... ^^;;;;

아래는 첫 번째는 원주율의 근사값을 계산하는 화면이며, 두 번째는 MINT64 OS를 테스트하는 동영상입니다. 워낙 허접해서 볼 건 없지만 기념삼아 찍어봤습니다.

<원주율을 계산하는 테스트>


<테스트 동영상>

어휴~ 이제는 동적 메모리 관리랑 파일 시스템쪽을 구현해야 하는군요. ㅠㅠ 어흑 어찌나 갈길이 먼지... 머리가 살살 아프네요. ㅠㅠ 일단 자고 내일 생각해야겠습니다. ㅠㅠ

그럼 다들 좋은 밤 되세요 ;)

ps1) 파일 압축쪽도 추가해야하는데... 혹시 소스 파일하나 짜리 Zip 압축/해제 코드를 보신 분은 제보 부탁드립니다. ㅠㅠ 출처를 밝히고 당겨 써야겠어요. ㅠㅠ

ps2) 실제 PC에서 테스트해보니, 더 느리군요. ㅡ_ㅡa... 그래서 태스크의 수를 300개로 줄였습니다. 아무래도 화면에 출력하는 루틴이 시간을 많이 잡아 먹는 듯 하네요. ^^;;;

에궁~ 8시 경에 집에 와서 시간까지 작업을 강행한 결과~!!! 드디어 프로세스와 스레드 관련 부분도 어느 정도 마무리되었습니다. ;) 와아~ 짝짝짝~!!!

거의 끝난 기념으로 무엇을 할까 고민을 많이 했었는데~ 후배가 매트릭스 화면을 만들어 보는 게 어떻겠냐는 이야기를 해서 프로세스 1개와 1021개의 스레드를 이용해서 매트릭스 화면을 만들어 봤습니다. 아래는 인증샷 입니다.

사실 실제로 보면 글자가 줄줄 흘러 내리는 것이 보이는데... ㅡ_ㅡa... 스크린 샷으로는 그런 느낌이 나질 않아서 약간 아쉬움이 남는군요. ㅎㅎ 조만간 실행 파일을 정리해서 한번 올리겠습니다.

아우 벌써 또 이만큼 시간이 지났네요. ;) 일단 오늘은 자고 내일 정리해서 올리겠습니다. ㅎㅎ 다들 좋은 밤 되세요 ;)

거의 3주 만에 올라오는 Milestone이군요. ;) 중간 중간에 올릴 수도 있었는데... 일정에 좀 쫓기다 보니 마음이 급해서 그러질 못했네요. ;)

image

<멀티 레벨 큐 스케줄러가 도입된 화면> 

그 동안 MINT64 OS에 많은 변화가 있었습니다. 그 중에서 첫 번째는 라운드 로빈 스케줄러에서 벗어나 멀티 레벨 큐가 도입된 것입니다. 큐는 0~5까지 총 5개의 레벨로 구분되고, 우선 순위에 따라 적당히 레벨을 설정해 주면 스케줄러가 레벨에 따라 회수를 달리하여 열심히 스케줄링 해줍니다. 위의 스크린샷은 현재 수행 중인 태스크의 우선 순위를 변경한 후, 프로세서 사용률을 출력한 화면입니다. 태스크를 Sleep 없이 계속 실행했더니 사용률이 98%까지 올라갔군요. ㅠㅠ

image

<동기화 수행 전, 숫자의 순서가 일정치 않으며 출력된 카운터의 수가 15개가 안됨>

두 번째는 동기화 처리를 위해 뮤텍스(Mutex)가 추가된 것입니다. 동기화 처리에서 빠지지 않는 것이 두 태스크 간에 변수 하나를 공유하면서 덧셈이나 값을 출력하는 예제인데, OS 책을 몇 권 보신 분은 이제 지겨운 예제일 것입니다. 저도 처음에는 왜 이런 단순한 예제를 가지고 설명하는 것일까 하고 생각했습니다만, 반대 입장이 되어 보니 이제서야 알겠더군요. ㅡ_ㅡa... 그것만큼 설명하기 쉽고 간단한 예제가 없더라구요. ^^a... 그래서 결국 태스크 3개가 하나의 변수를 1씩 증가시키면서 5번씩 메시지를 출력하여 1부터 15까지를 출력하는 예제를 작성했습니다. ㅡ_ㅡa...

동기화를 하지 않으면 당연히 위 처럼 제대로 출력이 안되며... 뮤텍스를 이용하면 아래처럼 예쁘게 출력됩니다. 이제 조금만 더 하면, 어느 정도 실행 테스트 가능한 버전을 공개할 수 있겠군요. ;)

image

 <동기화 수행 후, 숫자의 순서가 1씩 증가하며 총 15개의 메시지가 출력됨>

아유~ 이제 이번 주는 스레드에 대한 내용을 정리해야 하는데... 벌써부터 머리가 아프네요. ㅠㅠ 어쨌거나 열심히 해야겠습니다. 호환, 마마보다 무서운 것이 일정이 밀리는 일이니까요. ;)

그럼 다들 좋은 밤 되세요 ;)

크윽... 이번 달은 지출이 많아서 자제를 하려 했지만... 도저히 불편해서 질러야겠습니다. 아시는 분은 아시겠지만, 전 이미  24인치 모니터를 쓰고 있습니다. 아래처럼 말이지요. ㅎㅎ

image

<저의 절친... 24인치 모니터에 MINT64 OS를 구동한 화면입니다. ㅎㅎ>

그런데 이렇게 넓디 넓은 24인치 모니터도 자료를 정리할 때면 한없이 좁아지더군요. 문서 정리하랴 스펙 보랴 코드 붙여 넣으랴... ㅠㅠ 창을 전환하느라 정신이 없을 지경입니다. 사실 이렇게 작업하면서도 지금까지 뭐가 불편한지 모르고 있다가, 얼마 전에 코드를 붙여 넣는 중에 짜증이 나서 알게됬습니다. 도저히 안되겠다 싶더군요. 그런데 이때 문득 떠오른 것이 있었으니... 바로 삼성에서 만든 노트북용 모니터 랩핏(Lapfit, LD190)입니다. ㅠㅠ)-b

어떻게 생겼냐하면 아래 사진의 우측처럼 생겼습니다. 기존 모니터와의 차이점이라면 목이 일단 없고 전력 소모가 22W까지 떨어졌다는 것입니다. 그리고 USB로 연결할 수 있다는 것도 하나의 장점입니다. ;) 옛날 멤버십 과제에 비슷한 게 있었는데... 혹시 그분들이 만든 게 아닌지 모르네요. ^^;;;;

image

안그래도 모니터가 너무 커서 일반 모니터를 두기가 애매했는데, Lapfit은 24인치 모니터 바로 아래에 둘 수 있어서 좋은 것 같습니다. 특가로 파는 곳이 있어서 좀 싸게 샀는데... 단점이라면 배송이 늦다는 것 정도...(ㅠㅠ 아흑~ 이쁜아 빨리와라~ ㅠㅠ 니가 빨리 안와서 오빠가 불편하잖니 ㅠㅠ)

아아~ 실력에 비해 작업 환경이 너무 좋군요. ㅠㅠ 살짝 반성을 해야겠습니다. ㅠㅠ 뭐~ 열심히 하려고 산거니 열심히 하면 되지 않을까요? ㅎㅎ ;) 나중에 배송되면 설치해서 다시 인증 샷을 올리겠습니다. 그리고 성능도 같이 말입니다. ㅎㅎ

이궁~ 그럼 오늘도 슬슬 작업을 시작해야겠군요. 다들 좋은 밤 되세요 ;)

이번에는 정말 아슬 아슬하게 기한을 맞췄군요. ㅠㅠ

시간이 너무 늦었으니 오늘은 그냥 화면만 올리고, 자세한 것은 내일 올리겠습니다. ;)

아래는 실행 화면입니다. ㅎㅎ 5개의 우선 순위를 설정할 수 있도록 수정 되었고, 그 외에 뭐 태스크 종료 기능과 우선 순위 변경 기능, 그리고 프로세서 사용률 측정 기능이 추가되었습니다. ;)

clip_image002

이크~ 이만 자야겠군요. 내일 또 회식이 있어서... ^^;;; 다들 좋은 밤 되세요. ;)

clip_image002[8]

에휴~ 이번 주부터 2주 동안은 MINT64 OS에 스케줄러를 구현할 예정입니다. 이번 주는 다음 주에 구현할 멀티 레벨 큐 스케줄러(Multi Level Queue Scheduler)를 위해 간단한 라운드 로빈 스케줄러를 넣고 있습니다. 좀 있으면 주말인데, 주말에 약속이 좀 있어서 과연 이번 주 안에 끝낼 수 있을지 모르겠군요. ^^;;;;

시간은 점점 흘러만 가고 진도는 잘 나가지 않는 가운데... 뭐 회사에 대한 고민들과 퇴사하는 후배의 모습이 겹쳐서 머리가 좀 뒤죽박죽입니다. ㅠㅠ 이거 원... 이런 불경기에 월급 안 깎이는 것만해도 고마워 해야 할 텐데 말입니다. ㅠㅠ 아무래도 배가 부른 것 같군요. 개구리 올챙이적 모른다고 병특 때 고생한 건 생각도 안 하는 듯... ㅠㅠ

에궁... 정신 똑바로 차려야겠습니다. 홧팅~!!! >ㅁ<)-b

ps) 위의 화면은 라운드 로빈 스케줄러를 구현해서 20개의 태스크를 생성한 화면입니다. 대부분의 OS가 그렇듯이 PIT Interrupt를 통해 태스크를 전환합니다. ^^;;; 원래 각 태스크가 화면 주변을 돌게 되어 있는데, 스크린 샷을 찍다보니 그냥 잡다한 글자만 보이는 군요. 약간 슬프다는(?)...

image 

헥헥... 이번 주와 지난 주에 좀 많이 놀았더니 진도 맞추기가 힘드네요. ^^;;;; 어쨌거나 겨우 맞췄습니다. 아슬아슬 했다랄까요 ^^;;;; 자칫 잘못했으면 오늘 밤도 거의 못 잘 뻔 했습니다. ㅠㅠ 크윽... 이게 뭐 하자는 짓인지... ㅠㅠ

이번 주는 멀티 태스킹에 관련된 기능을 정리했습니다. 멀티 태스킹의 핵심이라하면 당연히 컨텍스트(Context) 관리 기능이므로, 컨텍스트 처리에 대한 함수 위주로 작성했습니다. 결과는 위에서 보시는 것과 같이 대~성공~!!!! 두 개의 태스크가 전환하면서 서로 자기 차례라고 메시지를 우기고(?) 있는 모습입니다. ^^;;;; (사실 예전에 다 만들었던 코드를 붙여 넣은 것 밖에는 없어요 ㅠㅠ)

다음 주는 이것을 확장해서 스케줄러도 추가하고 태스크 생성 및 종료에 대한 API도 추가해서 나름 괜찮은 시분할 멀티 태스킹 기능을 추가할 예정입니다. 점점 회사 일에 압박이 들어오고 있어서 생각대로 잘 될지는 알 수 없지만, 그래도 열심히 하는 것 말고는 방법이 없군요. ^^;;;; 제 유일한 장점이 책상에 오래 앉아 있는 거니 이거라도 살려야지요 ㅎㅎ

아아~ 이제 다음 주를 위해 준비를 좀 해야겠습니다. 다들 그럼 좋은 밤 되세요 ;)

ps) 크윽... 귀신보다 무섭다는 일요일 밤이군요. ㅠㅠ 눈물납니다. 아주 그냥 ㅠㅠ

MINT64 OS에 대해서는 간만에 포스팅하는 것 같습니다. 그 동안 회사 일도 좀 바빴고, 컨디션 난조로 생각보다 진도가 잘 안 나가는 바람에 조금 늦어 졌습니다. 블로그에 포스팅하는 시간까지 아껴가며 집중해야 했기 때문이지요. ㅠㅠ 결국 어쨌거나 목표했던 기간은 맞췄습니다. ㅎㅎ

이번에는 시간에 관련된 디바이스에 대한 기능을 추가했습니다. 흔히들 많이 쓰는 PIT 컨트롤러와 RTC, 그리고 정밀한 시간 측정 시에 사용하는 Time Stamp Counter(TSC)에 관련된 기능을 추가한 것이지요. 그리고 덤으로 쉘에 이러한 정보를 출력할 수 있는 기능도 추가했습니다.

만들어 놓고 보니 뭔가 재미있는 게 없을까 하는 생각이 들더군요. 그래서 마침 PIT도 있고 TSC도 있겠다 싶어서 프로세서의 클럭을 간접적으로 측정하는 코드를 삽입했습니다. TSC가 프로세서의 클럭을 기반으로 동작하는 특성을 이용해서, 약 10초 동안에 TSC가 변화한 양을 구하고 그것을 10으로 나누면 얼추 비슷하게 클럭을 측정할 수 있습니다. 다음은 MINT64 OS에서 측정에 사용한 코드입니다. 아래 코드로 측정했을 때 2667MHz가 나왔는데 실제 PC의 클럭이 2.6GHz짜리이므로 큰 차이가 나지 않는 다는 것을 알 수 있습니다.



이걸로 또 한 고비를 넘었습니다. ;) 이제부터 몇 주 동안은 멀티 태스킹 기능을 작업하면서 정리해야 하는데, 갈길이 막막하네요. ^^;;;; 코드를 짜는 거야 이미 지겹도록 했으니 아무 문제 없는데... 정리가 만만치 않아서... 쿨럭..;;; 이것 참 큰일입니다. 에혀... 그래도 어쨌거나 해봐야지요. >>ㅑ~울~!!!

에궁~ 빡시게 달릴 이번 주를 위해 오늘은 좀 일찍 자야겠습니다. 다들 좋은 밤 되세요 ;)

이번 주 금요일에 급히 쉘 관련 파트를 끝내고, 주말 내내 PIT 컨트롤러쪽 작업을 하면서 문서를 정리하고 있었습니다. 처음에는 진도가 꽤나 잘 나가는 듯 했으나, 언제나 그렇듯이 문제에 봉착했습니다.

PIT 컨트롤러의 카운터 0를 사용하는 경우, IRQ 0 인터럽트가 발생하기 때문에 인터럽트를 통해 간접적으로 타이머가 완료되었음을 알 수 있습니다. 하지만 인터럽트가 "언제나" 가능하지는 않기 때문에, 직접 카운터 0를 읽어서 처리하는 함수를 만들었습니다. 처음 작성한 코드는 대략 아래와 같았습니다.


실행해보니 뭔가 이상했습니다. 함수를 실행하자마자 루프를 바로 빠져나왔기 때문입니다. 이상해서 곰곰히 코드를 보고 있었는데 도무지 감을 잡을 수가 없었습니다. 그러던 중... 갑자기 머리를 팍~!! 하고 뭔가 스쳤습니다. 차를 구할 때 이전 값보다 현재 값이 크다고 생각했기 때문에, (현재 값 - 이전 값)으로 구했는데.... 타이머의 카운터는 증가하는 것이 아니라 1씩 감소했던 겁니다. 즉 이전 값이 현재 값보다 더 크다는 것이지요. ㅠㅠ 코드가 제대로 동작하려면 아래와 같이 순서를 바꿔야 합니다.


어흑... 이것 때문에 몇시간을 날렸는지 모르겠네요. 이것 말고도 손가락으로 초를 쟀다가 시계의 초보다 1.5배는 빨리 카운팅해서... ㅠㅠ 디버깅을 계속한 걸 생각하면... 흑흑... ㅠㅠ 왜 손가락으로 카운팅하는 속도와 초침이 움직이는 속도가 같다고 생각했는지... ㅠㅠ

그래도 어떻게든 해결했으니 다행입니다. 에궁... 이번 주 안에 RTDSC랑 RTC 쪽도 끝내려고 하는데... 시간이 될런지 모르겠군요. 이번 주도 미친듯이 집에 일찍 와야겠습니다.

다들 좋은 밤 되시고, 이번 주도 무사 칼퇴근하시기 바랍니다. ;) 야근불가~!!!

드디어 사고를 치고 말았습니다. ㅠㅠ)-b 어제 기안이 결재 되었다는 이야기를 듣고 출판사에 다녀온 것입니다~!!! 왠지 모를 불안감과 기대감에 가슴이 두근두근하더군요. ㅎㅎ 가서 담당하시는 분도 뵙고 이런 저런 이야기를 나눴는데, 너무 인상 좋으시고 성격도 좋으셔서 깜짝 놀랐습니다. “역시 이 바닥은 둥글 둥글한 사람들이 살아 남는구나” 하는 생각이 들더군요. ;)

한 손에 책을 가득 들고 출판사를 나오면서, 이제 진짜 열심히 해야겠다는 생각이 들었습니다. 뭐랄까요... 분위기가 사뭇 다른걸 느꼈다고나 할까... 지금까지 막연히 열심히 해야겠다고 생각한 게 확 깨면서, 언제까지는 뭐 하고 언제까지는 뭐 하고 이런 계산이 팍~!! 되더군요. 크윽... 이제 잠은 다 잤습니다. ㅠㅠ

올해 안에 마무리하는 걸로 목표를 잡고 열심히 달려 보겠습니다. ;) 화이팅~!!!

ps) 위의 스크린 샷은 현재 작업 중인 콘솔 쉘의 화면입니다. ;) 이것도 이제 곧 마무리 되겠군요.

크악... 이제 슬슬 쉘을 만들까 해서 sprintf() 함수를 구현하고 있었습니다. 처음에는 cdecl을 강제로 줘서 예전에 스택 어드레스로 하던 가변 인자 처리 방법을 써볼까 했는데... 64bit gcc는 cdecl을 줘도 무시하더군요. ㅡ_ㅡa... 그것도 당당히 무시한다는 경고까지 띄우고 말입니다. ㅡ_ㅡa...

그래서 결국 중계 역할을 하는 함수를 하나 둬서, 함수 Call 시에 레지스터로 넘어간 파라메터를 스텍에 집어 넣은 후  sprintf() 함수를 불렀습니다. 스택에 파라메터가 다 들어가 있으니 당연히 예전 방식대로 처리할 수 있었지요. ;) 그런데 의외의 곳에서 낭패를 봤습니다. ㅡ_ㅡa.... 다음 코드를 보시죠. ㅠㅠ


아시는 분은 아시겠지만, “...”으로 함수 파라메터를 정의했다면 다른 함수로 “...” 을 넘겨줄 수 없습니다. 쿨럭..;;; 왜 이걸 생각 못했는지... 그래서 예전에 쓰던 va_arg() 시리즈 물은 혹시 잘 될까 싶어서 써 봤는데... 의외로 링크 에러가 안 나는 겁니다. 그래서 정의된 곳으로 가서 확인했더니 라이브러리 함수가 아닌 builtin 함수를 가리키고 있더군요. ㅡ_ㅡa... 그냥 바로 코드로 전환되어서 링크 에러가 안 났던... ㅠㅠ

진작 이놈들을 썼으면 훨씬 전에 끝났을 텐데... vsprintf() 함수나 구현하고 sprintf()랑 printf()는 vaprintf()를 사용하도록 변경해야겠군요. Calling Convention 때문에 고민 꽤나 했었는데... 왠지 허무합니다. ㅠㅠ 에궁... 이렇게 또 하루를 날려 먹는다는... 그나저나 매번 가변 인자 때문에 고생했었는데, 좋은 걸 알았네요. ㅎㅎ 이제 걱정 안해도 되겠습니다. ;)

아우... 일단 자고 내일 일찍 와서 마무리를 해야겠습니다. 그럼 다들 좋은 밤 되세요. ;)


ps) CharSyam님이 지적하신 내용을 보고 본문을 다시 읽어봤더니, va_arg()를 라이브러 함수인 것 처럼 표현해서, 약간 수정했습니다. 본래의 의도는 va_arg()가 지시하는 함수가 라이브러리 함수가 아니라 builtinXXX 시리즈 함수라는 뜻이었는데, 마치 va_arg() 자체가 함수라는 것 처럼 썼더군요. va_arg() 시리즈는 매크로가 맞습니다. ;) CharSyam님 감사합니다. ;)

고향에서 엄마가 어찌나 바리바리 싸 주시던지... ㅎㅎ 올라오는데 종이 백이 찢어 질려고 해서 후덜덜하면서 올라왔습니다. :) 그래도 집에 와서 보니 흐뭇하네요 ;) 엄마 만세~~

짐 정리와 집 정리 좀 하고 컴퓨터 앞에 앉아 펩시를 마시고 있는데(펩시 짱~!!!)... “아~ 돌아왔구나” 하는 안도의 한숨과 “윽~ 내일 출근해야 하는 군하” 하는 통탄의 한숨이 같이 나오는군요. 크윽... 출근하기 싫어요. ㅠㅠ

에궁... 오늘 할 일도 많은데 언능 씻어야겠습니다. 그래도 이틀만 더 가면 다시 주말이니 힘내야겠어요 ㅎㅎ 언능 작업하고 자기 전에 또 MileStone이나 하나 올려야겠습니다. ㅎㅎ


좀 있으면 할머니 댁에 가야함에도 불구하고 일정이 좀 밀린지라 미친듯이 작업했습니다(그것도 설날 새벽에 이 짓을..~!!! ㅠㅠ). 그 결과~!!! 일단 목표치까지는 완성했습니다. ;) 아우 이거 원 노가다가 아주 장난이 아니군요. 그리고 생각 난 김에 MileStone 성 글에는 앞에 [MileStone]을 달기로 했습니다.

예전에 한번 달았다가 별로 효용이 없어서 블로그를 옮기면서 안달았는데... 글을 검색하려니 태그로 검색하는 것 보다는 제목으로 검색하는게 더 눈에 들어오더라구요 ㅎㅎ 앞으로 어떻게 될지는 모르겟지만, 일단 다는 걸로 했습니다.

[MileStone]을 달려고 글을 찾던 도중... 64bit로 최초로 전환해서 올렸던 글을 봤습니다. 작년 7월이더군요. 허허... 그후 가능성을 검토하기 위해 한 3개월 투자해서 GUI까지 후딱 만들고 지금 2번째 만들고 있는 건데... 그간 고생이 참 많았던 것 같습니다. ㅠㅠ 수많은 가상 머신들을 테스트하며 무료로 쓸 수 있고 멀티 코어까지 지원하는 놈을 찾기가 쉽지 않더라구요. 개발 환경은 또 왜이렇게 구축하기가 힘든건지... 지금 생각하면 눈물이 앞을 가립니다. ㅠㅠ

어쨋거나 지금은 검증까지 완료된 상태니 다시 그런 고생은 안하겠지요. ;) 옛날 글을 보니 감회가 새로워서 한자 끄적거려 봅니다. ㅎㅎ

이크~ 더 늦기 전에 이만 자야겠군요. 다들 떡국 많이 드시고, 새해 복 많이 받으세요 ;)


프로젝트 홈페이지: http://dev.naver.com/projects/nanumfont/


작년부터 GUI에 사용할 무료 폰트가 없을까 많이 고민했었는데, 어제 웹서핑을 하다가 네이버에서 공개한 무료, 그것도 고정 폭 글꼴을 찾았습니다. @0@)-b 비트맵 방식으로 처리하는데 고정 폭만큼 편한 게 없는지라 테스트를 위해 바로 설치해 봤습니다.


아래의 그림은 제가 주로 쓰는 Bitstream Vera Mono 폰트와 나눔고딕 코딩 폰트를 비교한 것입니다. Bitstream에 비해 샤프한 느낌이 나고 한글이 예쁘게 잘 나온다는 것을 알 수 있습니다. 헷갈리기 쉬운 숫자 0과 영문 O를 쉽게 구분할 수 있도록 한 것도 맘에 드는군요. ;)



<나눔고딕 글꼴>



<Bitstream Vera Sans Mono>


Bitstream을 보다가 나눔 고딕을 보니 약간 어색한 문자가 보이기도 하지만, 공짜로 쓸 수 있고 한글이 예쁘게 잘 나오기 때문에 향후 나눔고딕 폰트를 본 따 GUI를 만들 생각입니다. MINT64 OS가 한층 더 이뻐지겠군요. ;) 프로젝트를 진행하시는 분께 감사의 메일이라도 보내야겠습니다.


아우~ 이제 좀 있으면 고향으로 출발해야 할 시간이군요. 다들 즐거운 설 되시고 떡국 많이 드세요 ;)

아아~  지난 주에 내내 정리하고 작업해서 인터럽트 처리에 기반이 되는 IDT와 TSS쪽 관련 작업을 완료했습니다. 아우~ 이번에는 생각보다 정리할 것이 많아서 아주 식겁했습니다. 분량이 다른 것보다 1.5배나 많아서 죽는 줄 알았거든요. ^^;;;;

이것 참... 역시 어림짐작으로 대충 가늠했더니만, 이런 일이 생기는군요. ㅡ_ㅡa... 이것 말고도 대충 대충 잡아 놓은 부분이 아주 많은데... 살짝 겁이 나기 시작했습니다. 올해 안에 끝낼 수나 있을지 모르겠네요. 이건 뭐... 미친 듯이 정리하지 않는 한 어렵겠다는 생각도 얼핏 들었습니다.

어쨋거나 시작한 일이니 마무리는 해야겠고... 도중에 그만두자니 성격에 안 맞고... 역시 전 고생을 사서하는 타입인 것 같습니다. ;) 죽이 되던 밥이 되던 달려 봐야겠습니다. ;)

이크... 벌써 또 이렇게 시간이 됐군요. 이만 자야겠습니다. 다들 좋은 밤 되세요

ps) 맨 앞의 그림은 Divide by zero 예외를 발생시켜서 임시 예외 핸들러를 부른 화면입니다. 아주 허접하지만 Milestome 용으로 올려 봅니다. ;)

오늘 블로그를 돌다가 Xeraph 님의 블로그에서 재미있는 글을 봤습니다. “인텔 기가비트 NIC의 성능 향상 기법”이라는 내용이었는데, 원문은 http://xeraph.egloos.com/4808876 에서 보실 수 있습니다.

내용을 간단히 요약하자면 기가 비트쯤 되면 초당 무시무시한 패킷이 오고 가는데, 이것을 패킷이 올 때마다 인터럽트를 발생하게 하여 처리하면 인터럽트 처리의 오버 헤드 때문에 시스템의 전체적인 효율이 떨어진다는 것입니다. 어차피 패킷은 주기적으로 들어온다고 가정하면 인터럽트가 아닌 타이머를 사용할 수 있고, 주기적으로 패킷을 한꺼번에 읽도록 하면 효율을 높일 수 있다는 내용입니다.

실제로도 인터럽트가 자주 발생하면 현재 수행 중인 컨텍스트를 저장하고 복원하는 오버 헤드 때문에, 시스템의 성능이 급격히 떨어지게 됩니다. 저도 그런 경험을 한번 했었는데, 이 글을 읽고 나니 번뜩 떠오르더군요. 예전에 2003년쯤 자작한 kkama OS를 구동시키기 위해 펜티엄 2 233Mhz를 가진 노트북을 샀었습니다. Dell사 꺼였는 데, 플로피 디스크를 내장하고 있었기 때문에 상당히 메리트가 있었지요. ㅎㅎ

OS를 만들면서 GUI도 갖다 붙이고, HDD도 갖다 붙이고 하다가 장난 삼아(?) 시리얼 포트 드라이버를 만들 때였습니다. 전송 속도를 115200으로 맞춰 놓고 PC에서 노트북으로 데이터를 전송했더니, 정상적으로 패킷이 수신되지 않는 문제가 발생했습니다. 이상하다 싶어서 전송하는 동안 아무런 작업을 하지 않았더니 제대로 수신되더군요.

몇 번을 반복한 결과 시리얼로 패킷이 전송되는 동안 OS가 비정상적으로 느려지고, 마우스와 키보드, 그리고 HDD의 인터럽트, 그리고 인터럽트 불가 지역을 동시 다발적으로 수행할 때 패킷이 빠진다는 것을 알았습니다. 순진하게 시리얼 포트의 인터럽트가 발생할 때 마다 패킷 하나씩만 읽어 가서 FIFO에 남은 패킷이 계속 인터럽트를 유발했던 것이지요. 그러다 보니 처리가 늦어지고  패킷은 FIFO에서 밀려 사라지고... 등등의 문제가 발생했었습니다.

해결 방안은 간단했습니다. 시리얼 포트의 FIFO 크기를 늘리고, 인터럽트가 발생했을 때 마다 FIFO에 있는 데이터를 모두 읽음으로써 인터럽트의 발생 회수를 줄인 것입니다. 더불어 인터럽트 불가 영역을 줄여서 인터럽트에 좀더 빨리 반응하도록 한 것도 도움이 됐습니다.

안 그래도 지금 OS를 새로 만들고 있는데, 이런 점을 고려해서 잘 만들어야겠다는 생각이 드는군요. 그 동안 잊고 있었는데, 이점을 고려하면서 해야 할 것 같습니다.

에궁... 그럼 이만 또 자야겠네요. ㅎㅎ 다들 좋은 밤 되세요 ;)

에궁... 테스트 버전의 키보드 드라이버를 MINT64 OS에 추가했습니다. ^^;;; 예전에 만든 OS는 필요한 키만 추려서 처리했는데, 이번에는 다 처리하도록 만들었습니다. 뭐 아직 정리가 좀 덜 되긴 했지만, 역시나 기록을 남긴다는 차원에서... ^^;;;

회사에서 맡은 일도 어느 정도 해결 한지라 부담 없이 작업에 몰두했더니, 밤이 꽤 깊었네요. 이만 자야겠습니다 . 자세한 포스팅은 내일 해야겠군요. ㅎㅎ 그럼 좋은 새벽(?) 되세요 ;)

안녕하세요, kkamagui 입니다. ;) 새해가 되어 처음으로 하는 포스팅이군요. 그간 일이 좀 있어서, 일도 좀 하고(휴가인데 말이죠... ㅠㅠ) 코드 정리 작업을 병행하다 보니 이제서야 하나 올립니다. ㅎㅎ 아우 휴가를 정신 없이 보냈네요. 그나마 위로 일찍 올라 왔으니 이 정도는 한 것 같습니다. 계속 밑에 있었다면 아마... GG ㅠㅠ

이제 월요일이 되면 다시 회사로 가야 하는 데... 끔찍하군요. 어디 짱 박혀서 하고 싶은 것만 하고 살 수는 없을까 심히 고려 중입니다. 나이라도 어리면 과감히 퇴사하고 다른 것에 뛰어들어 볼 텐데... 좀 있으면 꺾인 환갑이라 그럴 수도 없네요. ^^;;;; 그냥 회사 다니면서 잠 좀 줄여 이것 저것 하는 정도 밖에는.... 그나마 졸졸하던 칼퇴도 이번 달부터는 힘들듯... ㅠㅠ (아아~ 이거 난 언제 자라는 말이냐... ㅠㅠ)

위에 그림은 새로 정리해서 만든 MINT64 OS의 스크린 샷입니다. 점점 소스 공개가 불투명해지고 있는 상황에서 이런 스크린샷을 올리는 게 과연 옳은 일인지는 모르겠지만... 개발 기록을 남긴다는 차원에서 꾸준히 올리고 있습니다. 어찌됐던 빨리 마무리 되었으면 좋겠는데... 점점 알 수가 없네요. ㅠㅠ

앗... 벌써 시간이 이렇게... 일단 자야겠습니다. ^^;;; 다들 좋은 밤 되시고... 아 아니구나... 좋은 아침 되세요 ;)

http://kkamagui.tistory.com/614에 제 PC에서 테스트한 A20 게이트의 이상 증세에 대해 글을 남겼습니다. 생각 외로 많은 분들이 관심을 가져 주셨는데, 그 중에서 A20 게이트에 따른 주소 공간의 변화에 대한 내용을 한번 정리할 필요가 있어서 글을 하나 끄적 거립니다.

A20 게이트는 아시는 분은 아시겠지만 어드레스 라인 20bit에 관련되어 있습니다. 즉 A20 게이트가 비활성화 될 경우 어드레스 라인 20bit가 강제로 0으로 설정되어 홀수 Mbyte에 접근되지 않는 것이지요. ^^;;;; 물론 코드에서 홀수 Mbyte에 접근할 수 있지만 이것은 다시 짝수 Mbyte에 맵핑됩니다. 아래 그림을 보시면 한눈에 알 수 있습니다. 3Mbyte + 64Kbyte 영역에 접근하는 예를 나타냈습니다.



따라서 이 때문에 코드에서 사용하는 선형 주소는 짝수 Mbyte에 중복 맵핑되는 결과를 가져옵니다. 이로 인해 전체적인 주소 공간은 아래 그림과 같이 변환됩니다.

따라서 1Mbyte 이하의 위치에서 코드가 실행되는 상태에서 1Mbyte ~ 6Mbyte 까지 영역을 모두 0으로 초기화하는 프로그램을 실행한다면, 1Mbyte ~ 2Mbyte 영역을 초기화하는 순간 자신이 실행 중이던 코드 영역(1Mbyte 이하에 있는)을 모두 0으로 초기화하게 됩니다. 실행되는 코드는 1Mbyte 이하의 어드레스에 존재하므로 프로세서는 온통 0x00으로 도배된 코드를 실행하게되고, 이는 잘못된 인스트럭션이므로 예외(Exception)이 발생하게 됩니다. 즉 프로그램이 멈추거나 리부팅하게 됩니다.

이전에 글을 대충썼더니만, 증상에 대해서 오해하시는 분들이 있어서 다시 한번 정리합니다. ^^
휴일인데도 이런걸 하고 있는 걸 보면... 역시... ㅠㅠ)-b 골방 폐인인듯... ㅎㅎ

그럼 다들 즐거운 연말 보내세요 ;)

+ Recent posts