Arm Linux Kernel Hacks

#Reference

프로세스 소개

  | 프로세스란/ 태스크란/ 스레드란

프로세스 확인하기

프로세스는 어떻게 생성하나?

  | do_fork() 함수 소개

  | 유저 레벨 프로세스 생성 시 _do_fork() 함수 흐름

양극화는 우리 사회가 겪고 있는 심각한 문제 중 하나다. 

양극화를 아주 이해하기 쉽게 설명하면, 

잘사는 가정에서 태어난 아이들은 평생 부유한 환경과 유리한 조건에서 살고 못사는 집안의 아이는 평생 라면만 먹고 산다는 것이다. 

양극화의 가장 큰 원인은 교육 기회의 박탈이다. 못사는 집안의 아이들은 부유한 가정의 아이들에 비교해 교육 환경이 좋지 못하니 좋은 대학에 가지 못하고 이로 좋은 회사에 취업도 못해 가난의 대물림이 계속된다는 것이다. 

이 문장을 임베디드 개발 양극화 관점으로 바꿔 표현해보자. 

좋은 개발 부서에서 실무 프로젝트를 수행한 개발자는 계속 실력이 향상하며 좋은 대우를 받으나 허접한 개발 부서에서 개발을 시작한 개발자는 개발 능력이 업그레이드되지 않아 평생 라면만 먹으며 낮은 연봉을 받으며 일한다는 것이다. 

그러면 임베디드 개발자도 양극화가 있을까? 내가 겪어 본 바로는 개발자 양극화도 심하다고 본다. 

내가 말하는 양극화는 기회의 박탈이다. 즉 실무 경험을 통해 개발 능력을 키울 기회를 의미한다. 

임베디드 개발자 등급도 소고기 등급과 같이 특급부터 3등급까지 여러 등급으로 나눌 수 있는데 언제 등급이 매겨지는지 살펴보자. 

가장 크게, 임베디드 개발자 등급은 취업할 때 입사하는 회사에 따라 나눠진다. 

여기서 말하는 회사는 연봉과 이름값만을 의미하지 않는다. 역량 있는 개발자로 성장할 수 있는 실무 프로젝트를 할 수 있는 회사다. 

아래 조건에서 임베디드 시스템을 개발을 시작하는 개발자는 우선 3~4등급으로 분류될 수밖에 없다. 왜냐? 

제대로 개발을 안 하니 실무능력이 쌓이지 않기 때문이다. 

1. 임베디드 장비로 디바이스 테스트만 하거나 시간을 많이 갈아 넣으면 할 수 있는 소모적인 일을 하는 개발 부서 

2. 코딩한 줄 하지 않고 다른 업체가 포팅한 드라이버를 올려 테스트를 하며 갑질을 하는 개발 부서 

3. 이미 안정화된 리눅스 커널에 드라이버 코드만 약간 수정하면서 프로젝트를 진행하는 개발 부서 

4. 남들이 해 놓은 드라이버를 컴파일이나 빌드를 빨리 해서 디바이스에 올리는 일을 하는 개발 부서 

회사의 이름 네임밸류가 높거나 연봉이 높다고 해도 이런 조건으로 일하는 임베디드 개발자의 역량을 인정해 줄까?

절~대 그렇지 않다. 

임베디드 개발자의 생명은 디버깅 능력이라 생각한다. 디버깅 능력은 문제 해결 능력과 직결되며 문제 해결 능력이 없는 개발자는 이 업계에서 인정해주지 않는다. 그런데 제대로 실무 프로젝트를 맡으며 만나는 여러 문제를 해결하는 과정이 필요한데 이런 **기회**를 박탈당한 개발자는 디버깅 기술 역량이 업그레이드되지 않는다. 

내가 여러 임베디드 모임이나 친구들과의 교류로 알게 된 사실은 많은 한국 임베디드 회사는 제대로 개발을 안 한다는 것이다. 

그 이유는 한국 임베디드 IT 업체들은 실리콘 밸리에 있는 개발자와 경쟁할 수 있는 원천 기술이 녹아 있는 소프트웨어를 개발하려는 의지가 보이지 않기 때문이다. 대부분 미국 등 해외 업체가 구현한 소프트웨어를 올려서 커스터마이즈하는 수준의 일을 하는 경우가 많다. 

그럼 이제 1차 관문에서 다른 임베디드 개발자 등급은 가려졌으니 이제 1등급부터 특급으로는 가는 길만 있지 않을까? 

하지만 현실은 그렇지 않다. 운 좋게 1차 관문을 통과해서 좋은 회사에 취업해도 3~4등급으로 떨어질 수 있다. 

제대로 실무 경험을 쌓을 수 있는 회사에 배치됐다고 해도 그 부서 배치나 그 부서의 개발자 육성 정책에 따라 개발자 등급이 또 나뉘기 때문이다. 

1. 회사의 운명을 결정 짓는 최신 임베디드 시스템을 개발하는 부서에 배치된 경우 

- 쟁쟁한 개발자 틈에서 맨날 테스트만 한다. 

- 핵심 디버깅 기법은 핵심 개발자들끼리 이야기하고 공유하지 않는다. 

- 맨날 이메일을 쓰면서 다른 업체 인터페이스 역할만 한다. 

2. 정치 싸움에 밀려 개별화만커스터마이즈만 하는 프로젝트를 하는 개발 부서에 배치 

- 빌드 머신이 되어 하루에 3~4개씩 이미지를 배포하고 테스트만 한다. 코드 분석할 시간은 물론 없다. 

- 커스터마이즈만 하는 일만 하는 부서이니 선배 개발자 개발 능력이 허접해 배울 것이 없다. 

이름 값하는 회사에서도 벌레처럼 기어다니듯 개발자도 수 없이 많다.

제대로 개발 능력을 키울 수 있는 프로젝트에 투입되는 것이 현실에서는 **정말** 쉽지 않다. 

1~2 관문을 통과하고 정말 실무 경험을 키울 수 있는 프로젝트에서 일하면 특급 개발자가 될 수 있나? 

그렇지 않다. 끊임없는 노력으로 학습을 해야 특급 개발자가 될 수 있는 것 같다.

리눅스 커널은 오픈 소소다. 모든 개발자나 학생들이 소스 코드를 들여다볼 수 있어 많은 정보를 알 수 있다. 함수 이름과 자료 구조를 보면서 리눅스 커널을 익힐 수 있다. 

난 운영체제를 소스 코드를 보면서 익힐 수 있는 리누즈 토발즈 및 오픈 소스 정신을 부르짖는 분들께 감사를 드리고 싶다. 리눅스 커널이 오픈 소스 프로젝트가 아니였다면 난 아마 RTOS 운영체제로 임베디드 디바이스 개발을 했거나 아예 다른 오픈 소스 프로젝트에 뛰어들었을 지도 모른다.

RTOS 회사가 알려주는 운영체제 개념도를 보면서 **그려러니** 하며 머릿속 개념으로 남아 있을 것이다.  

오픈 소스인 리눅스 커널로 누리는 혜택(?)이 있지만 만만치 않은 걸림돌이 있다.

리눅스 커널 소스 코드를 이해하면서 읽기가 너무 어렵다는 것이다. 구조체와 자료 구조가 너무 복잡하다. 

또한 리눅스 커널 소스에서 매크로를 정말 많이 쓴다. 그런데 매크로가 매크로를 5중으로 치환하면서 함수에서 쓰는 매크로 실제 값을 알기도 어렵다.

한 가지 예를 들어보자. 다음은 워크 멤버 중 data 필드로 워커 풀을 읽는 함수다.

static struct worker_pool *get_work_pool(struct work_struct *work)

{

unsigned long data = atomic_long_read(&work->data);

int pool_id;

assert_rcu_or_pool_mutex();

if (data & WORK_STRUCT_PWQ)

return ((struct pool_workqueue *)

(data & WORK_STRUCT_WQ_DATA_MASK))->pool;

pool_id = data >> WORK_OFFQ_POOL_SHIFT;

if (pool_id == WORK_OFFQ_POOL_NONE)

return NULL;

return idr_find(&worker_pool_idr, pool_id);

}

WORK_STRUCT_WQ_DATA_MASK이란 매크로 변수가 어떤 값인지 바로 이해할 수 있나?

다음 코드 선언부와 같이 WORK_STRUCT_FLAG_MASK 매크로를 알려면 WORK_STRUCT_FLAG_MASK, WORK_STRUCT_FLAG_BITS, WORK_STRUCT_COLOR_SHIFT, WORK_STRUCT_COLOR_BITS 매크로를 알아야 한다.

WORK_STRUCT_FLAG_MASK = (1UL << WORK_STRUCT_FLAG_BITS) - 1,

WORK_STRUCT_WQ_DATA_MASK = ~WORK_STRUCT_FLAG_MASK,

WORK_STRUCT_FLAG_BITS = WORK_STRUCT_COLOR_SHIFT +  WORK_STRUCT_COLOR_BITS,

WORK_STRUCT_COLOR_SHIFT 매크로를 분석하려고 하는데 어라? CONFIG_DEBUG_OBJECTS_WORK이란 컨피그에 따라  WORK_STRUCT_COLOR_SHIFT값이 달라진다. 

enum {

WORK_STRUCT_PENDING_BIT = 0, /* work item is pending execution */

WORK_STRUCT_DELAYED_BIT = 1, /* work item is delayed */

WORK_STRUCT_PWQ_BIT = 2, /* data points to pwq */

WORK_STRUCT_LINKED_BIT = 3, /* next work is linked to this one */

#ifdef CONFIG_DEBUG_OBJECTS_WORK

WORK_STRUCT_STATIC_BIT = 4, /* static initializer (debugobjects) */

WORK_STRUCT_COLOR_SHIFT = 5, /* color for workqueue flushing */

#else

WORK_STRUCT_COLOR_SHIFT = 4, /* color for workqueue flushing */

#endif 

최소 3~4년 리눅스 디바이스 드라이버를 만지면서 실무 개발에 뛰어든 개발자들을 제외하고 리눅스 커널을 처음 소스 코드로 공부한다는 것은 불가능하다. 

다른 이유는 뭘까? 

분석 중인 소스 코드가 실제 리눅스 시스템에서 어떻게 실행하는지 모르기 때문이다. 좀 유식한 말로 콜스택을 알 수 없기 때문이다.  

또한 분석 중인 코드가 컴파일되는 코드인지 모를 때도 있다. 

아예 컴파일 되지 않는 코드를 깊게 분석을 하는 가련한 개발자들을 보면 참 측은한 마음이 생긴다. 말 그대로 개삽질을 하고 있기 때문이다.

리눅스 커널을 익히기 어려운 또 다른 이유는 뭘까?

리눅스 커널을 쉽게 익힐 수 있는 툴이 부족하다. C# 프로그래밍을 하려면 C#용 Studio 프로그램을 설치하고 코딩을 하면 된다. 

그런데 리눅스 커널을 쉽게 설치하고 코딩할 수 있는 시스템이 있나? 사실 없다고 봐야 한다. 컴퓨터에 Ubuntu를 직접 설치하고 크로스 컴파일러 환경을 설정한 후 일일이 명령어를 입력해야 한다. 시스템에서 구동시키려면 엄청 손이 많이 간다. 

마지막으로 리눅스 커널을 쉽게 설명한 책이나 블로그도 없다. 

너무 이론 위주로 설명된 책이 대부분이라 신입 개발자들은 무슨 소리인지 알기 어렵고 블로그도 대부분 소스 코드 몇 줄 복사해 놓고 간단한 분석 내용을 요약해 놓은 수준에 불과하다. 

해외 신입 리눅스 개발자들은 한국과 상황이 약간 다르다. 해외 사이트의 경우 Stack Overflow나 영어로 된 리눅스 커널 입문자들을 위한 사이트가 많다. 영어만 제대로 해도 많은 정보를 얻을 수 있다.

리눅스 커널은 오픈 소스 프로젝트이지만 한국 신입 개발자들에겐 사실상 오픈 프로젝트가 아니다. 리눅스 커널 앞에 거대한 기술 장벽이 있다는 생각이 든다.

하지만 한국의 경우 이런 리눅스 커널을 익히기 위한 인프라가 절대적으로 열악하다.

4차 산업 혁명 시대가 열리면서 리눅스 디바이스 수요도 증가하고 있다. 수요 맞게 리눅스 커널 인프라를 한국에도 깔 필요가 있다.