OS 커널의 구조와 원리 : 1. 부트 스트랩

Real Mode 와 Protected Mode

Real Mode란 머퓨터에 전원이 들어온 후 CPU가 처음 움직이기 시작하면서 활동하는 모드. 리얼모드에서는 프로그램이 한 번에 한 개씩밖에 동작하지 못한다. 그리고, 한 프로그램은 현재 컴퓨터가 가지고 있는 램의 모든 영영ㄱ을 자기 마음대로 사용할 수 있다.

프로그램이 C 언어 함수 while(); 등으로 무한루프를 돌리면 도중에 사람이 인터럽트를 걸어서 멈추기 전에는 어느 다른 프로그램도 실행시킬 수 없기도 하고, 램 영역의 모든 부분에 접근할 수 있었기 때문에 DOS의 중요한 시스템 영역을 실수로든 악의로든 망쳐놓아 컴퓨터가 제대로 작동을 못하게 되는 경우도 허다했다. 현재는 하드웨어의 제어가 간단하다는 이유 등으로 제어용으로 사용하거나 하는 특별한 경우를 제외하고는 DOS는 거의 사용되지 않는다.

그런데 이 Real Mode를 아직까지 사용하고 있는 이유는 예전에 사용되던 8086 CPU용의 DOS 프로그램을 현재에도 계속 사용할 수 있도록 하는 호환성 문제 때문이다. 486을 사용하든지 Pentium을 사용하든지 리얼 모드가 동작하고 있을 때에는 CPU가 모두 하드웨어적으로 8086이 되어 있다고 생각하고 프로그램을 작성해야 한다. 따라서 모든 커널은 컴퓨터에 전원이 들어온 후 리얼 모드에서 여러 가지 하드웨어적인 세팅을 마친 후 프로텍티드 모드로 CPU를 전환한다.

Protected Mode란 현재 많이 사용되고 있는 Microsoft Windows나 Linux가 CPU에서 동작되고 있는 모드이다. 이 모드에서는 모든 프로그램이 한꺼번에 동작한다. 정확히 얘기하면 Protected Mode에서는 유저모드와 커널 모드의 두 가지 모드로 다시 나뉘어지는데, 프로그램들은 실행하는 도중 아직 끝나지 않은 상태에서 CPU가 갑자기(정해진 루틴에 의하여) 커널 모드로 들어가면서 커널의 루틴에 의해 멈추어지게 되고, 다른 프로그램이 이 커널의 루틴에 의해 길행되는 식으로 순서대로 조금씩 조금씩 실행된다. 그리고 각 프로그램이 사용할 수 있는 램의 영역도 커널의 루틴에 의해 정해지게 되고, 더 필요하면 커널 모드로 들어가서 요청하여 허락을 받고 얻어오는 방식을 취한다. 당연히 커널 모드의 영역은 유저 모드 프로그램에서는 정해진 루트 외에는 접근을 할 수 없다.

말하자면 모든 프로그램이 CPU를 공평히 사용하여 CPU시간이라는 소중한 자원의 낭비를 없애고 메모리를 아무렇게나 사용하지 않도록 해서 메모리 낭비를 없애는 관리를 커널 루틴이 해주는 효율적인 것이 Protected Mode이다.

현재 사용되는 대부분의 OS는 Protected Mode에서 동작한다.

 

Message queue 갯수 조절하기

리눅스에서는 여러가지 IPC(Interprocess Communication) 을 지원한다.

그 중, 메시지 큐의 경우 기본으로 잡혀있는 Open 가능한 최대 갯수는 16개로 지정되어 있는데, 간혹 여러 개의 메시지 큐를 사용하는 프로그램을 사용한다거나 등의 이유로 많은 갯수의 Message Queue가 필요한 경우 에러가 발생한다.

오늘 있었던 일도 그 중 하나였는데, 계속 해서 프로그램 구동시, Message Queue의 생성이 실패하며 자꾸 프로그램이 죽는 현상이 발생했다. 한참을 고민하다가 선임의 도움으로 해결할 수 있었다.

문제의 파악은 icps -q 명령어로 시작한다.

현재 운용 중인 많은 수의 메시지 큐. 이것이 문제였다.

[cube@cube1 RUN]$ ipcs -q

—— Message Queues ——–
key        msqid      owner      perms      used-bytes   messages
0x00015d40 0          cube       666        0            0
0x00015d41 32769      cube       666        0            0
0x00018388 1441794    cube       666        0            0
0x00018389 1474563    cube       666        0            0
0x000182bb 5079044    cube       666        0            0
0x000182eb 5111813    cube       666        0            0
0x000182ec 5144582    cube       666        0            0
0x000182b9 5177351    cube       666        0            0
0x000182ba 5210120    cube       666        0            0
0x000182bc 5242889    cube       666        0            0
0x0000ea60 5505034    cube       666        0            0

 

곧바로 확인 해 본 생성가능한 메시지 큐 갯수. 16개다. 당연히 문제가 생길 수 밖에.

[cube@cube1 RUN]$ ipcs -lq

—— Messages: Limits ——–
max queues system wide = 16
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384

구글링을 해보니 커널소스의 msg.h 헤더 파일에서

#define MSGMNI 16 /* <= IPCMNI */ /* max # of msg queue

부분을 원하는 양으로 수정한 후, 다시 커널 컴파일을 수행하면 된다고 한다. 하지만 저 부분 하나만을 위해 커널 컴파일을 하기에는 너무 비효율적이다. 다행히 다른 방법이 있었다.

sysctl 명령어를 통한 수정 방법도 있었다. 재부팅이 되면 이 설정은 다시 초기화가 되지만 방법과(rc.local 파일에 설정한다거나..) 때에(잠시만 사용할 경우) 따라서는 요긴한 방법이다.

root 계정으로 로그인한 후, sysctl 명령어를 통해 메시지 큐의 갯수를 늘리는 방법은 아래와 같다.

sysctl -w kernel.msgmni=32

다음은 위의 명령어 이후에 확인한 메시지 큐의 내용들이다.

[cube@cube1 RUN]$ ipcs -q

—— Message Queues ——–
key        msqid      owner      perms      used-bytes   messages
0x00015d40 0          cube       666        1            1
0x00015d41 32769      cube       666        0            0
0x00018388 1441794    cube       666        0            0
0x00018389 1474563    cube       666        0            0
0x000182bb 5079044    cube       666        0            0
0x000182eb 5111813    cube       666        0            0
0x000182ec 5144582    cube       666        0            0
0x000182b9 5177351    cube       666        0            0
0x000182ba 5210120    cube       666        0            0
0x000182bc 5242889    cube       666        0            0
0x0000ea60 5505034    cube       666        0            0
0x0000ea61 5537803    cube       666        0            0
0x0000ea62 5570572    cube       666        0            0
0x0000ea63 5603341    cube       666        0            0
0x0000ea64 5636110    cube       666        0            0
0x0000ea65 5668879    cube       666        0            0
0x0000ea66 5701648    cube       666        0            0

 

[cube@cube1 RUN]$ ipcs -lq

—— Messages: Limits ——–
max queues system wide = 32
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384

 

Changing gnome ternimal title on ubuntu linux

그놈 터미널을 사용하던 중, 터미널의 제목이 변경되지 않는 문제점을 발견했다.

평소에는 신경쓰지 않다가 꼭 한번씩 여러개의 창을 동시에 띄워 놓았을때, 헷갈려서 제대로 된 작업 공간을 찾기까지 꽤나 여러번 창을 이동해야 했던 불편함이 있었다.

며칠을 미루다 이번에 변경을 하여 그 내용을 포스팅한다.

간단하다. 위의 그림 처럼 자신의 홈디렉토리 내에 .bashrc 파일의 제일 아래쪽에 아래의 라인을 추가해주면 된다.

PROMPT_COMMAND=’echo -ne “33]0;${USER}@${HOSTNAME}: ${PWD/$HOME/~}07″‘

WordPress Error – Fatal error: Cannot redeclare class Facebook in /wp-content/plugins/simple-facebook-connect/facebook-platform/facebook.php

워드 프레스를 사용하던 중 아래와 같은 에러를 발견하였다.

WordPress Error – Fatal error: Cannot redeclare class Facebook in /wp-content/plugins/simple-facebook-connect/facebook-platform/facebook.php

관리자 계정으로 로그인 하여 글을 수정 하려고 했는데 위와 같은 에러가 발생하면서 로그인이 안되는 현상이었다.

에러 메시지의 원인은 메시지 내용에 나타나있었다. Facebook 관련된 플러그인에서 오류가 발생하여 로그인을 할 수 없다는 내용이다. 오류가 발생한 이유는 중복 선언.

구글링 후 해결방법을 찾을 수 있었다. 내용인즉, 설치된 두개 이상의 페이스북 플러그인이 서로 작동하면서 충돌이 일어난 것이란다.

웹서버에 ssh 접속후, 에러가 발생한 플러그인 디렉토리를 다른 이름으로 변경 후, 다시 접속을 하니 정상적으로 로그인이 되었다.

로그인 후, 문제가 발생한 플러그인을 삭제하여 문제를 해결하였다. 🙂

noeol – NO End Of Line

APUE 예제를 따라하다가 이상한 부분을 발견했다.

예제 파일을 실행한 후 생성된 결과 파일을 Vi 에디터로 열었더니 아래의 스크린샷처럼 나온 것.

파일 안의 내용은 정상이다. 하지만 문제점은 마지막 부분 “file.hole” [noeol] 부분.

리눅스를 사용하기때문에 자주 Vi 에디터를 사용하는 나로서는 처음 보는 메시지였기에 관심이 갔다. 찾아보니 원인은 간단.

http://www.computing.net/answers/unix/last-line-is-not-complete/7506.html

의 경로에서 그 내용을 확인할 수 있었다.

내용인즉, 파일의 마지막 줄이 Line Feed (개행문자)로 끝나지 않아서 vi에서 그 내용을 알려주는 부분이라는 것이다.

위의 경고를 없애고 싶다면 간단하다. 마지막 라인의 마지막째에 빈칸을 삽입하던가 혹은 echo “” >> file.hole 과 같은 방법으로 빈줄을 하나 추가하면 된다.