안녕하세요~ ^^

아직... 세살 칭호가 돌아오지 않네요... ^^;; 허허 ^^;;

지난번에 제가 제 블로그의 글을 퍼왔었습니다~^^;;

목적은 이런 방면으로도 많은 맛클러 분들의 관심이 닿았으면 하는것이었습니다^^

이런 글을 적고 올린다고 해서 제가 뭐 좀 아는것도 아닙니다~

초보인 제가 좀 더 안드로이드가 무엇인지 도대체 어떻게 움직이는 것인지에 대해 궁금증을 가졌다가

몇 가지 알게된것을 정리했었던 내용을 퍼오는 것이기 때문에 저 같은 초보 분들의 관심을 끌기에 조금은 더

도움이 될 수 있지 않나 싶네요~^^

쉬운 내용은 아니지만... 그렇다고 어려운 내용은 결코 아닌듯 합니다 ^^

뭐 아직 저도 너무 모르긴 하지만요 OTL... ^^;; 허허 ^^;;

지난번에 init process 에 대해 썼던 두개의 블로그 글 중 첫 번째 글을 퍼왔었고~

오늘 두 번째 올렸던 글을 퍼옵니다~^^

지난번에 자유 게시판에서 Bvlgari 님의 요청으로 유저노하우 게시판으로 옮긴적이 있어서 오늘은 바로

주제 넘지만 유저 노하우게시판에 글을 올립니다 (__)

지난번 처럼 제 혼자만의 블로그 이고 사실 글 자체를 누가 보는걸 전혀 신경쓰지 않고 공부한것을

필기한다는 개념으로 몇달 전에 적었던 글이기 때문에 다소 건방진 말투로 구사되었다고 느끼실 수 있습니다.

양해를 부탁드립니다...

사실은 맛클이랑은 상관없이 적었는데...

이런 쪽도 관심을 많은 맛클러 분들이 갖는것이 아주 조금이나마 맛클에 도움이 되지 않나 싶어서

퍼옵니다~ 이해해 주세요~ (__) ^^

------------------------------------------------------------------------------------------------------------

일주일만에 다시 init process 에 대해 정리를 한다.
주중에 루트 권한을 필요로 하는 application 에 대해 간략하게 3 장에 걸쳐서 정리를 하였다.
앞으로 얼마나 더 많은 루트 권한을 필요로 하는 application 을 더 사용하게 될지는 모르겠지만 사용하는 데로
추가적으로 정리를 할 생각이다.

처음에는 theme 를 변경하는 쪽으로 관심이 생겼다가 그 부분보다는 근본적인 android 자체에 대해 궁금증이 생겨서
시작하게 된 공부가 흥미롭게 진행되고 있다.

지난 init process_1 에서는 init process 가 하는 일과 init.rc 에 대해 적었다.
부족한 부분이 많은것 같지만 지금으로써는 그 정도 수준 이상은 아는것이 없기 때문에 나중에 추가적으로 공부를 하면서
알게되는 사항들을 업데이트 할 생각이다.
생업이 바빠지기 전에 가능한 모든 공부한 내용을 블로그에 정리를 하려고 하는데 언제까지 글을 지속적으로 쓸 수 있을지는
아직 모르겠다. 일단은 먹고 살아야 스마트 폰이고 공부고 관심이 생기는 것이니...

이번 init process_2 에서는 device node file 에 대한 내용과 그 중 uevent 에 대해 간략히 알아보고 init process 의
자식 process 와 property service 에 대해 적을 것이다.
(주로 custom kernel 을 build 하는 쪽에 관심이 있는 경우는 init.rc 의 내용분석까지가 주요 관심사가 될것 같으며,
device node 와 관련된 내용부터는 크게 손댈것이 없을것 같다는 생각이든다.)

*. device node file 생성
우리가 사용하는 application 은 device driver 를 통하여 hardware 에 접근을 한다. 그리고 이러한 application 이
device driver 에 접근하기 위해서 사용하는 것이 device driver 의 logic file 인 device node file 이다.
mknod 라는 device 생성 utility 가 android 에서는 제공이 되지 않기 때문에 일반적인 linux 와는 다르게 device node file 을
생성한다.

device node file 은 /dev directory 에서 정의가 된다. 그런데 /dev directory 는 항상 존재하고 있는 directory 가 아니고
booting 과정에서 init process 가 /dev 를 생성한다.
init process 는 두 가지의 방법으로 device node file 을 생성한다.

첫째는 cold plug 방식이다.
이 방식은 미리 정의된 device information 을 바탕으로 init process 가 실행될 때 일괄적으로 device node file 을 생성한다.

둘째는 hot plug 방식이다.
이 방식은 system 동작 중 usb port 에 장치가 삽입될 때 event 처리로 init process 가 해당 device 의 device node file 을
동적으로 생성한다.

hot plug 방식에 대해 먼저 적어보면 아래와 같다.
linux kernel 의 버전이 2.6 을 넘어가는 경우 mknod utility 가 없어도 자동으로 device node file 을 생성하도록 만들어진
daemon 이 존재하는데 이 daemon 이 udev(userspace device)이다.
udev 의 device node file 생성과정을 보면 아래와 같다.
kernel 이 해당 device 에 대한 driver 를 loading 하게 되면 driver 의 함수가 시작되게 된다. 함수 내에서 /sys file sytem 에
driver 에 대한 정보를 저장하게되고, udev process 에 uevent 를 발생시킨다.
발생된 uevent 를 통해 udev daemon 에서 message 를 분석하여 /sys directory 에 등록된 device information 을 보고
/dev directory 에 device node file 을 생성시킨다.

-- uevent --
kernel 에서 userspace 의 process 로 message 를 전달하기 위한 신호체계이다. uevent 는 device 의 이름, 종류, 주 변호,
부 번호, device node file 이 생성될 경로 정보를 담고 있으며, 이른 udev daemon 에 절달하는 역할을 한다.
위의 내용처럼 uevent 를 분석하여 udev daemon 이 /dev 에 device node file 을 생성시키는 방법이 hot plug 방식 이며,
이러한 방식을 거친 application 이 device driver 를 통하여 hardware 에 접근을 하는 것이다.

hot plug 방식만을 사용한다면 한가지 문제가 발생한다. 그 문제는 udev daemon 자체가 booting 과정 이후 userspace 에서
동작하는 process 이기 때문에, kernel booting 과정에서 발생하는 device driver 의 uevent 를 처리하지 못하게 되는 것이다.
이러한 부분을 해결할 수 있는 방법이 cold plug 방식이다.

cold plug 방식에 대해 적어보면 아래와 같다.
udev daemon 실행 이전에 loading 된 device driver 에 대해 device node file 을 생성하는 방법이 cold plug 방식이다.
cold plug 방식은 device 가 삽입될 때 처리가 이루어지는 hot plug 와 달리 이미 삽입된 device 에 대한 처리를 담당하는
메커니즘이다. hot plug 에서 udev daemon 의 역할을 init process 가 수행하는 것이 cold plug 방식이라고 이해한다면
쉽게 이해할 수 있다. init process 가 실행되면서 /sys directory 에 미리 등록된 device information 을 읽어들인 후 각 device 에
대해 uevent 를 다시 발생시켜 device node file 을 생성하는 것이다. init process 는 cold plug 로 처리될 driver 들을 이미 알고
있으며, 각 driver 의 device node file 을 미리 정의해 두고 있다. open source 에서 /system/core/init/devices.c 의 내용을
보면 cold plug device 의 node file list 를 확인할 수 있다. init process 는 cold plug 처리 시에 devperms 구조체를
참고하여 /dev directory 에 device node file 을 생성한다.

-- devperms --
cold plug 될 driver 의 device node file 의 이름, 접근권한, 사용자 ID, 그룹 ID 를 나타낸다. 사용자가 정의한 새로운 device 에
대한 device node file 을 생성하고 싶으면 devperms 구조체에 해당 driver 의 information 을 추가하면 된다.

*. init process 의 자식 process 관리
init process 는 init.rc 로 부팅 parsing 한 service list 를 통해서 자식 process 를 순차적으로 실행한다.
이때, init process 가 실행하는 주요 process 에는 대표적으로
sh _ terminal, serial, adbd 접속 시 console i/o 를 제공하는 shell program
adbd _ android debug bridge daemon 이며, 기기의 상태를 관리하는데 사용되는 tool
service manager _ android system service 의 목록을 관리
vold _ volume daemon 이며, usb storage 나 sd card device 를 mount 하고 관리
위와같은 process 들이 있다.

init process 는 자식 process 의 종료와 재시작 여부의 관리를 수행한다.
그 이유는 service manager 와 같은 process 의 경우 예상하지 못하게 종료가 된다면, process 간 통신이나 그래픽 출력 및
기타 여러 기능을 사용할 수 없게 되기 때문이다. 항상 살아있어야 하는 process 와 일회성으로 실행 후 죽도록 되어있는
자식 process 를 백그라운드 에서 init process 가 계속적으로 관리를 해줘야 android system 이 안정적으로 구동이 된다.
이 때 알아야 하는 개념이 init process_1 에서 적었던 SIGCHLD 와 signal handler 의 개념이다.

간단히 init process 가 자식 process 를 관리하는 과정을 살펴보면 아래와 같다.
init process -> service list 내 자식 process 실행 -> 자식 process 생성 -> ~/~/~ -> 자식 process 종료 ->
SIGCHLD signal 발생 -> init process SIGCHLD 분석 -> 자식 process 의 option check -> oneshot 여부 확인
-> 자식 process 의 종료 처리 혹은 재 시작

-- oneshot --
process 가 가지고 있는 option 중의 하나이다. oneshot option 을 가지고 있는 자식 process 는 종료가 되면 발생된 SIGCHLD 를
init process 가 분석하고 난 후 process 의 option 을 check 하고 난후 oneshot option 이 존재하면 자식 process 의 재 시작을
수행하지 않고 종료를 유지하도록 logic 이 짜여져 있다.

*. property service
init process 의 event 처리 roof 에서 처리하는 enevt 중 property 변경 요청과 관련된 service 이다. android platform 은
system 이 동작하는 데 필요한 각종 설정 값을 동작 중인 모든 process 에서 공유하기 위해 property 라는 저장 공간을 사용하고 여기에 접근할 수 있는 API 를 제공한다. property 는 key = value 의 형태로 사용된다. android system 에서는 모든 동작 중인 process 는 property value 를 조회할 수 있지만, property value 를 변경할 수 있는 것은 init proess 만 가능하다. process
로 부터 요청을 받으면 init process 는 해당 process 의 property 접근 권한을 검사한 뒤 property value 를 변경한다.

좀 더 자세히 살펴본다면
init process 에서 property value 를 저장하기 위한 공유 momory 를 생성하는 데 이를 ashmem(android shared memory) 라고 한다. 외부의 process 들은 ashmem 으로 접근하여 property value 를 조회할 수 있는 것이다. 하지만 앞서 적은것 처럼 property value 는 변경할 수 없으며, 변경을 위해서는 init process 에 property value 변경을 요청해야 하며, 이러한 process 의 요청을
받는 init process 가 접근권한을 검사한 후 ashmem 내의 property value 를 변경하는 것이다.

-------------------------------------------------------------------------------------------------------------------

저도 제 글을 제가 퍼오면서 다시 한번 읽어보니~

새롭네요~^^