hacking의 파장(?) 으로 android.git.kernel.org 과 kernel.org 에 접속이 되질 않는다.
mirror site 로 받을 수 있다. 

https://github.com/android
 에서 android source를 checkout 받을 수 있다. 
(platform, kernel 등)

추가로, vanilla kernel 은 
https://github.com/mirrors/linux-2.6 에서 kernel.org 에서 받던 소스를 
받을 수 있다. 
kernel.org 복구가 완료 된듯. !!
1. Linux Cross Reference site 이용
 
사이트에 접속하면 빨간 박스를 클릭하여 최신 버전의 소스 최상위로 진입할 수 있다. 

선택후, 

빨간 동그라미 부분을 클릭하면 버전별 소스 트리를 선택할 수 있다. 일단 2.6.37.1 최신버전을 선택
그리고 바로 옆 search 박스에서 테스트로 "task_struct" 를 입력하고 search 버튼을 누른다. 

찾은 "task_struct" 두가지로 분류되어 있다. "Extern or forward variable declaration"(위의 그림) 과 "Structure"(아래 그림)
include/linux/sched.h 를 클릭하여 소스를 보도록 하자.

위와 같이 소스를 볼수가 있다. include file이나 각종 변수 및 선언된 내용(파란색 글)은 모두 클릭하여 연결된 소스를 웹에서 볼수가 있다. 

2. Program의 이용
분석툴로는 Linux 에서는 vim + ctags + cscope 방법과 Window에서 사용하는 SourceInsight 가 있다.(물론 유료버전임.. 30일 무료버전을 다운받아 사용해보는 것을 추천한다.) 

이미 내용을 잘 써놓은 블로그가 검색하면 쫙 나오기에.. 검색해보고 찾은 것중 참고할 만한 글을 링크합니다. 

a. http://sosal.tistory.com/11 커널 분석기(vim+ctags+cscope) 정리한 블로그 입니다. 
b. sourceInsight 사용법 : http://wizlog.net/60 (시작하기에 좋은 참고 블로그입니다.)
  - 한글 주석 입력방법 : http://jany.tistory.com/47

3. Get Linux Kernel Source
Web Browser : www.kernel.org
빨간 박스는 최신버전을 바로 다운로드 할 수 있는 링크임.

국내 미러 사이트의 주소는 
여기서 v숫자(ex. v2.6) 를 클릭하여 들어가면 관련 버전의 소스를 다운받을 수 있다. 

Console에서는 
wget을 이용한다.(없으면 설치해야함. ubuntu는 "sudo apt-get install wget" 하면됨.

$ wget -c http://<mirror site>/pub/linux/kernel/v2.6/linux-<version>.tar.bz2

version은 linux-2.6.23.7.tar.gz 이런 식으로 입력하면 됩니다. 
Chapter 2, Process Management and Scheduling


2.3 Process Representation
Process와 program에 관련된 Linux Kernel의 모든 알고리즘은 include/sched.h 에 정의되어 있는 task_struct 라는 data 자료구조 내부에 있다. 이 자료구조는 시스템의 중심적 역할은 하는 것들 중에 하나이다. scheduler의 구현부를 다루기 전에, 이 기본적인 자료구조를 알아야 한다. 

task 구조체는 많은 process를 연결하는 요소들을 포함하고 있다. 구조체 내부의 요소들을 잘 알지 못하고는 차후에 나오는 내용을 이해시키기는 어려울 것이다. 

task 구조체는 다음과 같이 정의되어 있다.

task_struct 소스 내용을 모두 넣는 것이 쓰는 사람도 읽는 사람도 불편할 것이니 다른 방법을 사용한다. 물론, 필요한 부분은 넣어야겠지..


task_struct 의 링크는 
이다. 링크에서 보는 바와 같이 2.6.37.1 version 의 소스이다. 책의 내용과 조금 차이가 있을 수 있다. 

소스를 보면 알겠지만, 이 구조체의 많은 정보를 다 소화하기란 어려운 일일 것이다. 그렇지만, 이 구조체를 process의 특정 한 상태를 표현하는 등의 부분 부분으로 나누어 본다면 조금 수월할 것이다. 

Process 상태 및 실행 정보 : 지연된 signal, 사용된 binary 포멧(또한 다른 시스템의 binary 포멧을 위한 emulation 정보 등), process ID(pid), 자신의 부모 process 및 관련 process의 연결 포인터, 우선순위 값, 마지막으로 program을 실행한 시간 정보(CPU time)

□ 할당된 가상 메모리(virtual memory) 정보

process 자격 : user ID, group ID, process가 특정 명령을 수행할 권한 정보 등. System call 을 통해 process 정보등을 확인 하고 변경할 수 있다. 

사용된 file : program code를 포함하는 binary file 뿐만 아니라 process가 다루는 모든 file의 filesystem 정보는 저장해야한다. 

□ Thread 정보, process의 CPU 관련 runtime data 를 기록하게 됨.(그 외 남은 구조체의 field 는 사용된 하드웨어와 의존적이지 않다 - stack 정보같은 것인듯.)

□ 다른 process와 함께 같이 작업할 때, Process간 통신(Interprocess Communication)에 대한 정보

□ process가 signal에 응답하기 위해 등록한 signal handler

task 구조체는 간단하게 값들이 구성되어 있지 않다. 각종 data를 연결하기 위한 포인터 등으로 구성되어 있다. 중요한 변수들 몇몇을 자세히 설명해본다. 



state 는 process의 현재 상태를 기술한다. (volatile long으로 선언됨) 

TASK_RUNNING : Task가 수행 가능한 상태이다. 이것은 실제 CPU에 할당되어 수행중이라는 것은 아니다. scheduler에 의해 선택될 때까지 이 task는 기다릴 수 있다. 이 상태는 process가 실행 가능한 상태이며 외부 event를 기다리고 있지 않다는 것이다. 

TASK_INTERRUPTIBLE : 어떤 event를 기다리는 잠자고 있는(sleeping) process를 위한 설정이다. 기다리던 event가 발생하게 되면, 이 상태는 TASK_RUNNING 으로 변경되면 scheduler에 의해 선택되면 바로 실행이 가능하게 된다. 

TASK_UNINTERRUPTIBLE : kernel의 명령으로 잠들어 있는 process를 disable 시킨 상태. kernel이 직접 해제하지 않는다면, 외부 signal에 의해 깨어나 수행할 수 없다.

TASK_STOP : process가 특정목적을 위해 멈춰있는 경우이다.(예를 들면, debugger의 break point에서 멈추게 함.)

TASK_TRACED : 이 process의 상태는 ptrace 매커니즘을 이용해 process가 특정 시점에서 trace되고 있는 상태로 일반적인 STOP 된 task와 구별하기 위함이다. 

이 다음에 나오는 상수는 종료되는 process의 상태를 나타내준다. 이것은 exit_state 항목에 저장된다.
EXIT_ZOMBIE : 2.2 에서 설명된 zombie 상태를 나타낸다.

EXIT_DEAD : 시스템에서 완전히 제거되기 전에 parent process에서 알맞은 wait system call을 호출한 뒤의 process 상태. 이 상태는 하나의 task 안에서 여러 개의 thread가 수행될 때 중요하게 사용되는 상태이다. 

Linux는 process의 시스템 resource 사용 제한을 위해 resource limit (rlimit) 메커니즘을 제공한다. 이 메커니즘은 task_struct 안에 signal 구조체 포인터가 있다. process signal 관리를 위한 구조체 내부에 rlim이라는 배열이 존재한다. ( 아마 책에는 task_struct 내부에 rlim 배열이 있다고 하는데, 소스를 보니 task_struct --> singal_struct *signal-->struct rlimit rlim[] 로 되어 있다.)

rlimit 구조체는 include/linux/resource.h 에 정의되어 있다. 

이 정의(definition)은 다른 많은 resource를 수용하기 위해 매우 일반적으로(?) 유지된다. 
rlim_cur : process의 현재 자원 제한. 이것은 soft limit 로 참조된다.
rlim_max : process가 허가된 최대 자원의 제한. 이것은 hard limit 으로써 참조된다.

setrlimit system call은 현재 자원제한을 증가시키거나 감소시키는데 사용한다. 그렇지만 이 값은 rlimt_max 값을 초과할 수 없다. getrlimit system call로 현재 limit 값을 확인 할 수 있다. 

이 제한적인 자원은 rlim 배열의 index로 자신의 위치를 확인 할 수 있는데, 이것은 kernel에서 상수값으로 미리 정의를 해두어 연결된 자원과 배열의 위치를 연결했다. Table 2-1을 보면 정의된 상수와 그것의 의미를 기술했다. System programming 책을 보면 자원 제한관련 예제 및 더 상세한 내용을 볼 수 있다. 또한, setrlimit(2) man page를 봐도 조금 더 자세한 내용을 볼 수 있다. 

 Linux 는 특정 유닉스 시스템과 binary 호완성을 제공하기 위한 노력을 해왔기 때문에 아키텍쳐 마다 상수의 값들은 서로 다를 수 있다.

limit은 kernel의 매우 다른 부분과 연관되어 있기 때문에, kernel은 반드시 대응되는 하위 시스템의 limit 값을 확인해야 한다. 

만약 resource type이 limits(거의 모든 자원의 기본 설정임) 설정 없이 사용되었다면, RLIM_INFINITY 의 값으로 rlim_max 가 설정된 것이다. 예외적으로 사용된 경우를 보자, 
□ 열린 파일들의 수(RLIMIT_NOFILE, 기본적으로 1024로 제한한다.)
□ 사용자가 가질 수 있는 process의 개수(RLIMIT_NRPROC)은 "max_thread / 2"로 정의한다. 여기서 max_thread는 global 변수이며, 가용한 RAM의 1/8이 thread 정보를 관리하는데만 사용하고 20개의 thread가 최소의 메모리만을 사용하도록 thread의 생성 개수를 정의한다. (이문장은 번역에 어려움을 겪어 최대한으로 부드럽게 하려고 노력하였음.)

init task를 위한 부팅 때 자원 자한은 include/asm-generic-resouce.h 안에 INIT_RLIMTS 로 정의되어 있다. 

각 process의 proc filesystem을 통해 rlimit 값을 확인 할 수 있다. 
현재 나의 system 정보는 : VMware Server 2.0.1에 Ubuntu 10.10을 설치했다. 10.10의 kernel version은 2.6.35-22 다. 
rlimit 값을 확인 하기 위해, 

proc/self/limits 파일을 읽었다. proc file system의 self 라는 file은 symbolic link 이며 현재 수행중인 process를 가르키고 있다. 

Table 2-1: Process 관련 자원 제한. 
 상수  의미
 RLIMIT_CPU  최대 할당 할 수 있는 CPU 시간
 RLIMIT_FSIZE  사용할 수 있는 file 최대 크기
 RLIMIT_DATA  data segment의 최대 크기
 RLIMIT_STACK  (user mode) stack의 최대 크기
 RLIMIT_CORE core dump file의 최대 크기 
 RLIMIT_RSS  Resident Size Set 의 최대 크기; 다른 말로는 process가 사용할 수 있는 
최대 page frame의 개수이다. 현재 사용되지 않은 것도 포함함.
 RLMIT_NPROC  실제 UID 에 연관된 사용자가 하나의 process를 가지고 생성할 수 있는
process의 최대 개수(fork의 제한 인듯) - 조금 더 알아봐야 할듯.
 RLIMIT_NOFILE  하나의 process가 제어할 수 있는 파일의 개수(open files)
 RLIMIT_MEMLOCK  swap 되지 않도록 할 수 있는 page 의 개수
 RLIMIT_AS  하나의 process가 차지할 수 있는 가상 주소 공간의 최대 사이즈
 RLIMIT_LOCKS  file lock의 최대 개수
 RLIMIT_SIGPENDING  지연된 signal의 최대 개수
 RLIMIT_MSGQUEUE  message queue의 최대 개수
 RLIMIT_NICE  non-real time process들을 위한 최대 nice 레벨
 RLIMIT_RTPRIO  real time 우선 순위의 최대치.



+ Recent posts