지풍@blog

아웃룩에 계정을 추가하거나 변경할 때 아웃룩 자체에서는 불가능하고 제어판의 "메일"으로 들어가서 추가하거나 변경하라고 경고 창이 뜨죠

제목은 거창하지만 비 아이팟 기기에서 iTunes를 MP3 관리 프로그램으로 쓰는 팁입니다

지금은 옴니아로 MP3를 듣지만 예전에는 아이팟 터치를 썼었고 그때는 iTunes로 MP3를 쉽게 아이팟 터치로 sync를 했죠
(단 MP3에 tag가 잘 정리되어 있다는 것을 전제하구요)

근데 옴니아로 와서는 단순히 파일 복사로 MP3를 옴니아로 넣다 보니까 중복도 생기고 관리가 어렵더라구요

목마른 자가 우물을 파는 법!!!

구글링을 해 본 결과 iTunes를 옴니아를 포함한 WM계열이나 다른 MP3 기기에서도 쓸 수 있도록 도와 주는 프로그램이 있더군요

바로 iTunes Agent ( http://ita.sourceforge.net )라는 프로그램을 쓰면 iTunes를 관리프로그램으로 쓸 수 있더군요

(다운로드 링크 : http://downloads.sourceforge.net/ita/ita-1.3.1-installer.exe?use_mirror= )

.Net Framework 2.0 이상 설치되어야 설치 가능하고  iTunes Agent를 설치하기 전에 먼저 당연히 iTunes가 설치 되어야 하구요 최신버전인 9.0.2.25버전에서도 호환이 되더군요


iTunes Agent를 설치하고 실행하면 오른쪽 하단 알림 아이콘에 iTunes Agent이 실행되고 조금더 기다리면 iTunes가 자동실행 됩니다


iTunes가 실행하면 재생목록에 My Devices가 생기는 것을 볼수가 있죠 그럼 설치는 제대로 되었고 iTunes를 옴니아나 다른 MP3기기에서 관리프로그램으로 쓸 수 있습니다


그럼 이제 설정을 해야하는데 오른쪽 하단 iTunes Agent 오른쪽 클릭을 하면 메뉴가 나오고 Preferences로 들어 갑니다

설정은 아래에 따라 정당히!!! 해주시면 됩니다

Name은 적당하게 이름으로 MP3기기 이름이나 장치 이름으로 써주면 되구요

Synochronize pattern은 만약 02 You Are My Girl.mp3(tag 제목:You Are My Girl, 가수:김조한, 앨범:지붕뚫고 하이킥 (MBC 일일시트콤) - Part.1, 곡번호:2)이란 파일이 있다면

iTunes는 "김조한\지붕뚫고 하이킥 (MBC 일일시트콤) - Part.1\02 You Are My Girl.mp3"으로

Artist Folder는 "김조한 - 지붕뚫고 하이킥 (MBC 일일시트콤) - Part.1\02 You Are My Girl.mp3"으로

Flat는 "김조한 - You Are My Girl.mp3"으로 MP3기기로 받을 수 있습니다

그리고 Music folder는 싱크를 받을 경로가 되는데

옴니아 같은 경우에는 Active Sync로 할 경우에 드라이브명이 안 나오기 때문에 쓸 수 없고

이동식 저장소 모드로 변경해야지 드라이브명이 나오기 때문에 쓸때는 이동식 저장소 모드로 변경해야 합니다

Recognize by folder/file에는 Music folder와 같은 경로로 지정해줍니다 그렇게 되면 싱크할 때 쓰는 파일을 같은 경로로 만들어 줍니다

Music folder와 다른 경로로 쓰면 싱크를 하면 Music folder 쪽으로 가는게 아니라 Recognize by folder/file 쪽 경로에 넣어 주니까 반드시 같은 경로로 해줘야 합니다

Associate with playlist는 iTunes의 어떤 곳에 있는 playlist를 sync할 것인지 설정하는 메뉴인데 

Use device name은 Name에서 설정한 이름이 "재생목록 - My Devices" 밑에 playlist가 생기는데 그 쪽에 있는 playlist를

음악은 "보관함 - 음악"에 있는 playlist를 My Devices는 "재생목록 - My Devices" 에 있는 playlist를 sync를 하게 됩니다

참고로 음악으로 설정하면 보관함 - 음악에 MP3만 넣으면 되니까 가장 쉽게 쓸 수 있습니다

이렇게 다 설정하고 Save 한 다음에 Preferences 창의 왼쪽 하단의 Save를 클릭하면 설정이 완료가 됩니다


이제 iTunes에 sync를 하고 싶은 MP3를 추가 시킨 다음에 iTunes Agent에서 Synchronize devices를 클릭하면 Music folder로 지정한 곳에 MP3가 들어 간 것을 볼 수가 있을 껍니다

그럼 이제 아이팟만 아니라 다른 MP3기기나 WM 계열에서도 iTunes로 MP3를 sync 받고 관리할 수 있을 겁니다!!!

CSCF는 호 처리에 관련된 부분 담당하는 기능으로 ICGW(Incoming CAll GateWay)와 CCF(CAll Control Function), SPD(Serving Profile Database), AH(Address handling)으로 구성된다. ICGW는 첫 진입점(entry point)로 동작하며 입력호에 대한 라우팅을 수행한다. 또한 호 스크리닝(screening) 및 포워딩과 같은 입력호에 대한 서비스 서비스 트리거링(triggering)을 수행하며 AH에 대한 질의, HSS와의 통신을 담당한다. CCF는 호의 설정과 종료 및 상태/이벤트 관리, 다자간 서비스를 위한 MRF(Multimedia Resource Function)과의 상호 작용, 과금을 위한 호 이벤트 보고, 응용 레벨 등록의 수신 및 처리 등을 담당한다. SPD는 홈 도메인의 HSS와 통신하여 사용자 프로파일 정보를 관리하며 사용자의 처음 엑세시 시 홈 도메인을 알려주는 기존 망의 VLR과 유사한 기능을 수행한다. AH는 주소를 분석, 변환, 수정하는 기능을 수행하며 주소 이동성 가능을 제공한다.

CSCF(Call Session Control Function)는 가입자가 위치하고 있는 망에 따라서 수행하는 기능이 다르므로 그 위치와 역할을 기준으로 해서 Proxy-CSCF(P-CSCF), Interrogating(I-CSCF), Serving CSCF(S-CSCF)로 논리적으로 구분할 수 있다.

1)P-CSCF
-사용자는 IM 멀티미디어망에서 접속하는 첫 포인트 지점이고, GGSN과 같은 도메인에 존재한다. P-CSCF의 주소는 “Local CSCF Discovery" 메커니즘을 사용하여 PDP context activation에 의해 사용자에게 전달된다.
-사용자로부터 수신한 SIP등록요구 메시지를 사용자의 홈 도메인을 참조하여 I-CSCF로 전달한다.
-사용자로부터 수신한 SIP메시지를 등록 절차를 통해 수신한 S-CSCF 주소를 이용하여 S-CSCF로 전달한다.
-사용자에게 SIP메시지를 요구 또는 응답한다.
-Emergency session을 검출하여 이를 처리할 S-CSCF를 선택한다.
-Change Data Record(CRD)를 발생한다.
-사용자와 Security Association을 유지한다.
-Bearer 자원의 권한 검증과 QoS관리를 한다.

2)I-CSCF
-사용자의 홈 망에 접속하는 첫 포인트 지점이고 하나의 네트워크 도메인에 여러 개가 존재할 수도 있다.
-사용자의 SIP 등록을 수행하는 S-CSCF의 주소를 IISS로부터 수신한 후 실제 등록을 담당한 S-CSCF를 할당한다.
-타 망으로부터 수신한 SIP 메시지를 S-CSCF로 라우팅한다.
-CDR을 방생한다.
-서로 다른 도메인 간의 SIP 메시지를 전달할 때 방확벽 기능의 Topology Hiding Inter-Nework Cateway(THIG)를 수행하여 망 정보의 일부를 보내지 않을 수도 있다.

3)S-CSCF
-사용자의 세션 제어하는 서버임을 HSS에 등록하고 이후 사용자의 가입자 정보를 다운로드 하여 저장한다.
-실제 등록된 사용자의 세션 상태관리를 하면서 제어 서비스를 수행한다.
-사용자에게 서비스 자원과 관련된 정보를 제공한다.
-사용자의 다이얼된 번호나 SIP URL을 통하여 착신 사용자의 홈 도메인의 I-CSCF의 주소를 얻는다.
-PSTN 또는 CS 도메인으로 라우팅하기 위해서 SIP 요구 및 응답메시지를 Breakout Gateway Control Function(BGCF)으로 전달한다. 이후 BGCF는 해당 PSTN/CD 도메인과의 상호 간의 제어를 담당할 MGCF를 선택하거나, 다른 BGCF로 전달한다.
-Multi-Party call 등의 서비스를 지원하기 위해 MRF로 인터페이스 한다.
-사용자의 등록 시에 HSS로부터 수신한 인증정보를 가지고 인증을 수행한다.
-P-CSCF의 기능을 수행할 수도 있다.
-CDR을 발생한다.


출처 : 한국표준협회 (http://www.it-standards.or.kr/information/information_detail.asp?page=15&idx=2752&selCd=01&txtKey=)

This is a simplified model of TCP/IP over Ethernet behaviour of a single TCP connection intended to provide insight into throughput limitations of TCP/IP due to network transit latency. In the model, TCP/IP sends the maximum TCP receive window size worth of application data (filling the maximum possible receive buffer), then waits for a single acknowledgement for the entire max. window size burst. The model also assumes that the instant the acknowledgement is sent, the data is emptied from the receive buffer and the entire window size is again fully available.

Analysis assumes no lost data (no retransmits are required, no delay associated with retransmit timer waits & no ACK timer waits); All datagrams sent are maximum size; No allowance for TCP slow start algorithm delay; This results in an upper bound style result. Bear in mind that this simulates the performance of a single application, not an aggregate usage model of multiple simultaneous users on a network. Furthermore, at the upper limit of TCP performance the model assumes that computer hardware and network equipment can sustain the peak TCP allowed data rates.

In Basic TCP, the maximum number of bytes that can be in transit (specified by the TCP receive window size) is limited to 64KB by the 16 bit window size in the TCP header. Often the 64KB value is used to illustrate the maximum theoretical throughput of TCP. This is only partially true. In the early 1990s Van Jacobsen et Al. recognized that higher bandwidths were becoming available and that TCP needed to be updated to support high bandwidth, high latency networks. The work culminated in 1992 with the publication of RFC1323 which specified modifications to TCP to support the high bandwidth, high latency networks. This removed the 64 KB limit, in theory.

In practise, most TCP stacks do not support RFC 1323 extensions and still have a maximum TCP window size on the order of 8 KB. An example is Microsoft TCP/IP v.2.0 used in Windows NT. It has a 8760 Byte maximum receive window. Windows 2000, while supporting RFC 1323 extensions, by default has a maximum receive window of 17520 Bytes. To enable the RFC1323 extensions in Windows 2000, registry entries must be manually adjusted.

   

Select Line Rate : Gigabit Ethernet

   

Custom TCP Receive Window (for best perf. Use even multiples of 1460) : 65536 Bytes

   

   

Data:

Ethernet Frame Size : 1518 Bytes

Ethernet Preamble : 8 Bytes

Interframe Gap : 12 Bytes

Total Inter-Frame Time : 1538 Bytes

Ethernet Overhead : 38 Bytes

Ethernet Data : 1500 Bytes

IP Datagram Overhead : 20 Bytes

TCP Datagram Overhead : 20 Bytes

Maximum User Data per Ethernet Frame : 1460 Bytes

Line Rate

Ethernet 10000000 10000000

Fast Ethernet 100000000 100000000

Gigabit Ethernet 1000000000 1000000000

   

Maximum TCP Receive Window : 65536 Bytes

Maximum Windows NT TCP Receive Window (on Ethernet) : 8760 Bytes

Maximum Windows 2000 TCP Receive Window : 17520 Bytes

   

Application Throughput:

Application Data Size/(Ethernet Serialization Delay + Round Trip Latency)

   

출처 : http://www.babinszki.com/Networking/Max-Ethernet-and-TCP-Throughput.html

비스타에서 한글 2007을 설치 하고 hwp 파일을 마우스 오른쪽 버튼으로 클릭하면 위와 같이 나옵니다

상당히 보기도 지저분하고 저 메뉴를 클릭 해도 아래와 같이 실행도 안 되고 자동 업데이트를 해도 해결 되지 않습니다

해결 방법은 레지스트리 편집기로 잘못된 키값을 지워 주면 깨끗이 해결됩니다
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Hwp.Document.7\shell\DefaultIcon

위 키값을 지워 주면 아래와 같이 해결됩니다

redhat 계열에서는(redhat, Fedora, Red Hat Enterprise Linux, CentOS등) 해당하는 배포판의 버전을 /etc/redhat-release에 해당하는 배포판의 버전이 있습니다

간혹 하위 버전의 배포판으로 만들어진 소스가 상위 버전의 배포판에서도 컴파일이 되지만

지원하지 않는 배포판이라고 컴파일이 안 될 경우에는 이 파일에 해당하는 하위 버전의 배포판으로 변경해 주면 됩니다

참고로 아래는 자주 쓰는 redhat 9 이랑 Fedora에서 redhat-release입니다

Fedora Core release 1 (Yarrow)
Fedora Core release 2 (Tettnang)
Fedora Core release 3 (Heidelberg)
Fedora Core release 4 (Stentz)
Fedora Core release 5 (Bordeaux)
Fedora Core release 6 (Zod)
Fedora Core release 7 (Moonshine)
Red Hat Linux release 9 (Shrike)

위 사진처럼 윈도우 업데이트시 폰트 크기가 커져 버려서 확인버튼이 나오지 않은 경우에는

<Alt> + A 키를 눌러서 확인을 강제로 누르게해서 다음으로 넘어 갈수 있습니다

인텔의 서버 프로세서 브랜드명은 Xeon(제온)이다.

Xeon은 다시 두가지 종류의 프로세스로 구분이 되는데, DP와 MP이다.
DP는 Dual Processor, MP는 Multi Processor의 약자이다.

1. Intel Xeon Processor (Paxvile DP)
90나노미터 공정의 프로세서로 Dual-Core Xeon Processor이다. HT(HyperThread)를 지원하므로 1CPU 한개당 4개(Dual-Core *  HT)의 Thread를 처리할 수 있으며, Lindenhurst Chipset기반에서 작동이 된다.

- Dempsy (뎀시)
65나노미터 공정의 프로세서

- Sossaman (소싸만)
초 저전력 프로세서로서 Yohna(모바일 프로세서)기반으로 31W의 저전력 프로세서

- Woodcrest (우드크레스트)
Core microarchitecture를 채택한 프로세서로, 일반 모델과 저전력 모델(LV)모델이 있다. LV 모델의 경우 소비전력은 40W로 초 저전력 서버 프로세서이다. 얼마전 시장에 나왔다.

- Clovertown (클로버타운)
Core microarchitechure기반의 Quad-Core 프로세서이다. Bensley 플랫폼의 일환으로 공급될 것이며 2007년 1분기에 출시 예정인 프로세서다.

2. Intel Xeon Processor MP (Paxville MP)
4 CPU 이상을 지원하는 Dual-Core Xeon Processor 명으로 Truland 플랫폼 기반으로 제공된다.

- Tulsa (툴사)
65나노미터공정 Dual-Core 기반의 프로세서로 16MB의 대용량 L3 캐시 메모리를 탑재한 서버 프로세서이다. 이 프로세서는 인텔의 가상화 기술과 캐쉬 메모리 보호 기술인 Pellston 기술을 채용하여 미션 크리티컬한 업무에 사용되는 고가용성 프로세서이다.

- Tigerton (타이거톤)
65나노미터공정의 Caneland 플랫폼에서 채택될 프로세서로, Core microarchitecture의 초고속 채널 연결 기술을 사용할 프로세서이다 출시는 2007년으로 예상

- Dunnington (더닝톤)
Tigerton을 잇는 프로세서로 2008년 출시 예정인 프로세서이다.

* 플랫폼 명칭 설명
- Bensley (벤슬리) : Intel Xeon DP
- Truland (트루랜드) : Intel Xeon MP
- Caneland (케인랜드) : 향후 MP 시리즈 플랫폼


출처 : http://cusee.net/2460475

C/C++의 Data Type 입니다. 그런데 이것은 OS나 컴파일러에 따라서 차이가 있을 수 있습니다. 가령 16비트OS에서 int 는 16비트이고, 32비트OS에서 int 는 32비트입니다. 여기서는 일반적으로 가장 널리 쓰이는 "비주얼C++ (32비트 버전)"를 기준으로 한 것입니다.

정수 자료형

실수 자료형

 출처 : http://mwultong.blogspot.com/2006/09/c-char-int-float-data-type-ranges.html

리눅스 부팅 프로세스 연구 (한글)
Master Boot Record 부터 사용자 공간 애플리케이션 까지 부팅 가이드

난이도 : 초급

M. Tim Jones, Consultant Engineer, Emulex

2006 년 8 월 18 일

리눅스® 시스템의 부팅 과정은 많은 단계들을 거칩니다. 표준 x86 데스크탑을 부팅하든 아니면 PowerPC®를 부팅하든 그 단계는 놀랍게도 많이 비슷합니다. 이 글에서는 리눅스 부팅 과정을 초기 부트스트랩부터 첫 번째 사용자 애플리케이션의 시작 단계 까지 설명합니다. 아울러 부트 로더, 커널 디컴프레션(decompression), 초기 RAM 디스크, 기타 리눅스 부트 엘리먼트를 설명합니다.

초기에 컴퓨터를 부트스트랩(bootstrapping) 한다고 하면 부트 프로그램이 포함된 종이 테이프를 공급하거나 프론트 패널 address/data/control 스위치를 사용하여 부트 프로그램을 직접 로딩하는 것을 의미했다. 오늘날 컴퓨터에는 부팅 과정을 단순화시키는 장치들이 장착되어 있지만 꼭 그렇게 단순한 것 같지는 않다.

리눅스 부팅 과정을 보다 높은 시각에서 조망해야지만 전체적으로 볼 수 있다. 그런 다음 각각의 단계를 자세히 살펴봐야겠다. 곳곳에 첨부한 소스 자료가 커널 트리를 연구하는데 도움이 될 것이다.


개요

그림 1은 리눅스 부트 프로세스 개요도이다.

시스템이 처음 부팅되거나 리셋되면 프로세서는 잘 알려진 위치에 코드를 실행한다. PC의 경우, basic input/output system (BIOS)이다. 이것은 마더보드의 플래시 메모리에 저장된다. 임베디드 시스템에 있는 CPU는 리셋 벡터를 호출하여 플래시/ROM의 알려진 주소에서 프로그램을 시작한다. 두 경우 모두 결과는 같다. PC가 훨씬 유연하고, BIOS는 어떤 장치들이 부팅 후보인지를 결정해야 한다.

부팅 장치를 찾으면 첫 번째 단계 부트 로더는 RAM으로 로딩되어 실행된다. 이 부트 로더는 길이는 512 바이트 미만이고 하는 일은 두 번째 단계의 부트 로더를 로딩하는 것이다.

제 2 단계 부트 로더가 RAM에 있고 실행되면 스플래시 스크린이 디스플레이 되고 리눅스와 초기 RAM 디스크 옵션(임시 루트 파일 시스템)이 메모리에 로딩된다. 이미지가 로딩될 때 2 단계 부트 로더는 제어를 커널 이미지로 전달하고 커널은 압축이 해제되어 초기화 된다. 이 때 2 단계 부트 로더는 시스템 하드웨어를 검사하고 첨부된 하드웨어 장치들을 열거하고, 루트 장치를 마운트 하고 필요한 커널 모듈을 로딩한다. 완료되면 첫 번째 사용자-공간 프로그램(init)이 시작되고 고급 시스템 초기화가 이루어진다.

여기까지가 리눅스 부팅 과정을 간략하게 묘사한 것이다. 이제 리눅스 부팅 과정을 보다 자세하게 살펴보도록 하자.


시스템 시작

시스템 시작 단계는 리눅스가 부팅되는 하드웨어에 기반하고 있다. 임베디드 플랫폼에서, 부트스트랩 환경은 시스템이 켜지거나 리셋될 때 사용된다. U-Boot, RedBoot, MicroMonitor 등이 그 예이다. 임베디드 플랫폼에는 일반적으로 부트 모니터가 장착된다. 이 프로그램들은 목표 하드웨어의 플래시 메모리의 특별한 영역에 있고 리눅스 커널 이미지를 플래시 메모리로 다운로드 하는 방식을 제공하고 이를 실행한다. 리눅스 이미지를 저장하고 부팅하는 기능 외에도 이 부트 모니터는 시스템 테스트와 하드웨어 초기화를 수행한다. 임베디드 환경에서 이러한 부트 모니터들은 제 1 부트 로더와 제 2 부트 로더를 관장한다.

PC에서 리눅스 부팅은 BIOS에서 주소 0xFFFF0로 시작된다. BIOS의 첫 번째 단계는 POST (power-on self test)이다. POST가 하는 일은 하드웨어를 검사하는 것이다. BIOS의 두 번째 단계는 로컬 장치 열거(enumeration)와 초기화이다.

BIOS 기능에 따라 사용처도 다르며, BIOS는 두 부분으로 구성된다. POST 코드와 런타임 서비스이다. POST가 완료된 후에 이것은 메모리에서 플러시(flush)되지만 BIOS 런타임 서비스는 그대로 남아있고 해당 운영 체계에서 사용할 수 있다.

운영 체계를 부팅하기 위해서 BIOS 런타임은 complementary metal oxide semiconductor (CMOS)에서 정의된 선호도 순으로 활성화 되고 부팅 가능한 장치를 찾는다. 부트 장치는 플로피 디스크, CD-ROM, 하드 디스크 파티션, 네트워크 상의 장치, USB 플래시 메모리 스틱이 될 수도 있다.

일반적으로 리눅스는 하드 디스크에서 부팅되고, Master Boot Record (MBR)에는 주 부트 로더가 포함되어 있다. MBR은 512-바이트 섹터이고 디스크의 첫 번째 섹터(sector 1 of cylinder 0, head 0)에 위치해 있다. MBR이 RAM이 로딩된 후에 BIOS는 제어권을 여기에 넘겨준다.


Stage 1 부트 로더

MBR에 있는 주 부트 로더는 512-바이트 이미지로서 프로그램 코드와 작은 파티션 테이블이 포함되어 있다. (그림 2) 첫 번째 446 바이트는 주 부트 로더이고 여기에는 실행 코드와 에러 메시지 텍스트가 포함된다. 그 다음 64 바이트는 파티션 테이블인데, 네 개의 파티션(각 16 바이트)의 레코드가 포함되어 있다. MBR은 매직 넘버(0xAA55)로 정의된 2 바이트로 끝난다. 매직 넘버는 MBR의 밸리데이션에 사용된다.

주 부트 로더의 작업은 2차 부트 로더(stage 2)를 찾아 로딩하는 것이다. 액티브 파티션을 찾기 위해 파티션 테이블을 검사한다. 액티브 파티션을 찾으면 테이블에 남아있는 파티션들을 검사하여 이들이 모두 비활성 상태인지를 확인한다. 확인이 되면 액티브 파티션의 부트 레코드는 장치에서 RAM으로 읽혀지고 실행된다.


Stage 2 부트 로더

2차 또는 제 2 단계 부트 로더는 커널 로더라고 불린다. 이 단계에서의 작업은 리눅스 커널과 선택적인 초기 RAM 디스크를 로딩하는 것이다.

주/부 부트 로더의 결합은 x86 PC 환경에서 Linux Loader (LILO) 또는 GRand Unified Bootloader (GRUB)이라고 한다. LILO는 몇 가지 단점을 갖고 있고 GRUB이 이를 수정했으므로 GRUB을 살펴보도록 하자. (GRUB과 LILO에 대한 자세한 내용은 참고자료를 참조하라.)

GRUB의 좋은 점은 리눅스 파일 시스템을 알고 있다는 점이다. LILO 처럼 디스크 상의 미가공 섹터를 사용하는 대신 GRUB은 ext2 또는 ext3 파일 시스템에서 리눅스 커널을 로딩할 수 있다. 2 단계 부트 로더를 3 단계 부트 로더로 만든다. Stage 1 (MBR)은 리눅스 커널 이미지를 포함하고 있는 특정 파일 시스템을 알고 있는 stage 1.5 부트 로더를 부팅한다. reiserfs_stage1_5 (Reiser 저널링 파일 시스템에서 로딩함) 또는 e2fs_stage1_5 (ext2 또는 ext3 파일 시스템에서 로딩함)가 좋은 예이다. stage 1.5 부트 로더가 로딩 및 실행되면 stage 2 부트 로더가 로딩될 수 있다.

stage 2가 로딩되면서 GRUB은 사용 할 수 있는 커널 리스트를 디스플레이 한다. (/etc/grub.conf에서 정의됨. /etc/grub/menu.lst 와 /etc/grub.conf의 링크 포함). 여러분은 커널을 선택하고 추가 커널 매개변수로 이를 수정할 수도 있다. 부트 프로세스에 보다 직접적인 관여를 하려면 명령행 쉘을 사용할 수도 있다.

Stage 2 부트 로더가 메모리에 있는 상태에서 파일 시스템이 참조되고 디폴트 커널 이미지와 initrd이미지가 메모리로 로딩된다. 이미지가 준비되면 stage 2 부트 로더는 커널 이미지를 호출한다.


커널

커널 이미지가 메모리에 있고 stage 2 부트 로더에서 컨트롤도 넘어왔다면 커널 단계가 시작된다. 커널 이미지는 실행 커널은 아니고 다만 압축된 커널 이미지이다. 일반적으로 이것은 zImage (압축 이미지, 512KB이하) 또는 bzImage (큰 압축 이미지, 512KB 이상)이고 이들은 이전에 zlib로 압축된 것이다. 커널 이미지의 앞에 있는 루틴은 최소한의 하드웨어 설정을 수행한 다음 커널 이미지에 포함된 커널의 압축을 풀고 이를 큰 메모리에 둔다. 초기 RAM 디스크 이미지가 있다면 이 루틴은 이것을 메모리로 옮기고 기록해 둔다. 루틴은 커널을 호출하고 커널 부팅이 시작된다.

bzImage (i386 이미지 용)가 호출되면 start 어셈블리 루틴(그림 3의 주 흐름도 참조)의 ./arch/i386/boot/head.S에서 시작한다. 이 루틴은 기본적인 하드웨어 설정을 수행하고 ./arch/i386/boot/compressed/head.S에 있는 startup_32 루틴을 호출한다. 이 루틴은 기본 환경(스택 같은)을 설정하고 Block Started by Symbol (BSS)을 청소한다. 커널은 decompress_kernel (./arch/i386/boot/compressed/misc.c에 있음)이라고 하는 C 함수를 호출하여 압축이 풀린다.

새로운 startup_32 함수(swapper 또는 process 0)에서, 페이지 테이블이 초기화되고 메모리 페이징이 실행된다. CPU 유형이 검사되고 아울러 FPU (floating-point unit)도 검사된다. start_kernel 함수가 호출되면(init/main.c) 일반(non-architecture specific) 리눅스 커널이 된다.

start_kernel을 호출하면 초기화 함수의 긴 리스트가 호출되어 인터럽트를 설정하고 보다 구체적인 메모리 설정이 이루어지고 초기 RAM 디스크를 로딩한다. kernel_thread (arch/i386/kernel/process.c)를 호출하면 init 함수가 시작되는데 이는 최초의 사용자 공간 프로세스이다. 마지막으로 유휴 태스크가 시작되고 스케줄러가 주도권을 잡는다. (cpu_idle 호출 후). 인터럽트가 실행되면서 선점 스케줄러는 주기적으로 주도권을 잡아 멀티태스킹을 수행한다.

커널이 부팅되는 동안 stage 2 부트 로더에 의해 메모리로 로딩된 initial-RAM disk (initrd)가 RAM으로 복사 및 마운트 된다. initrd는 RAM에서 임시 루트 파일 시스템의 역할을 하고 커널이 물리적 디스크를 마운트 하지 않고도 완전히 부팅될 수 있도록 한다. 주변 기기와 인터페이싱 할 때 필요한 모듈이 initrd의 일부가 될 수 있기 때문에 커널은 매우 작아질 수 있지만 그래도 여전히 많은 하드웨어 설정들을 지원한다. 커널이 부팅된 후에 루트 파일 시스템이 (pivot_root를 통해) 회전되고 이곳에서 initrd 루트 파일 시스템이 언마운트(unmount)되어 실제 루트 파일 시스템이 마운트 된다.

Init

커널이 부팅 및 초기화 된 후에 커널은 최초의 사용자 공간(user-space) 애플리케이션을 시작한다. 이것은 표준 C 라이브러리로 컴파일 된 첫 번째 프로그램이다. 이전에는 어떤 표준의 C 애플리케이션도 실행되지 않았다.

데스크탑 리눅스 시스템에서 시작된 첫 번째 애플리케이션은 일반적으로 /sbin/init이다. 하지만 꼭 이럴 필요는 없다. 임베디드 시스템은 init (/etc/inittab을 통해 설정됨)에서 제공하는 초기화를 거의 필요로 하지 않는다. 많은 경우에, 필요한 임베디드 애플리케이션을 시작하는 간단한 쉘 스크립트를 호출하곤 한다.


요약

리눅스가 그러하듯, 리눅스 부트 프로세스도 매우 유연하고 많은 프로세서와 하드웨어 플랫폼을 지원한다. 초기에는 loadlin 부트 로더가 있었다. LILO 부트 로더는 부팅 기능을 확장했지만 파일 시스템 인식 부분에서 부족했다. GRUB과 같은 최신 부트 로더가 생기면서 많은 파일 시스템(Minix 부터 Reiser 까지)에서 리눅스를 부팅할 수 있게 되었다.


필자소개

M. Tim Jones는 임베디드 소프트웨어 아키텍트이자 GNU/Linux Application Programming, AI Application Programming, BSD Sockets Programming from a Multilanguage Perspective의 저자이다. 정지 우주선용 커널 부터 임베디드 시스템 아키텍처, 네트워킹 프로토콜 개발에 이르기 까지 그의 커널 개발 범위는 광대하다. 그는 현재 콜로라도 롱몬트에 위치한 Emulex Corp의 컨설턴트 엔지니어이다.

출처 : http://www.ibm.com/developerworks/kr/library/l-linuxboot/index.html