Skills/Linuxworld 2017. 4. 26. 04:02

나에게 흥미로운 내용이 또 한가지 있다면, 파일시스템 관련 즉, I/O 관련 이슈이다.

이것은 천상 System Engineer 인 나로써는, 성능에 가장 영향을 미치는 부분중,

튜닝이 가능한 부분을 살펴보게 되기 때문일 것이다.

기사 본문(아직 유료) : https://lwn.net/Articles/720675/

일주일뒤 확인하면 무료일듯...

--------

밑의 댓글들 중에는 Kyber 에 대한 벤치마크 결과가 있냐고 묻기도 하고,

그 결과로 8ms 에서 1ms 으로 줄였다는 메일링 내용도 있기도 하며,
( http://marc.info/?l=linux-block&m=148978871820916&w=2 )

이런 스케쥴러가 BTRFS 같이 별도의 내부적 IO scheduler 나 Thread procedure 를 갖는
환경에서 정상동작 할지 우려하기도 하며,

확실한건 아닌데, 성능이 더 좋게 잘 동작하는것 같다고 하는 답변도 달려있다.

언제나, 리눅스는 물론, 시스템에 대한 엔지니어링을 하면서 항상 땔 수 없고,

내려놓을 수 없는 부분이 바로 성능이라고 생각된다.

디스크 성능에 대한 이야기를 쓰면서,

한때, 가상화에 한참 심취했을때, Disk I/O 에 대한 스케쥴러를 Deadline 과 NOOP 으로 바꿔

상당한 이득을 경험했을 때의 기억이 새삼 떠올랐다.

그때 엄청 감동이였는데... ㅎㅎㅎ

아무튼 리눅스의 성능에 중요한 요소인, Memory Management 와

Disk I/O scheduler 에 대한 것은 언제나 놓지 않아야 한다고 본다.

일단 술한잔 마시고, 예정화랑 구지성 같은 몸매종결 연애인들 나오는 프로 하악대며 보다보니,

어느덧 네시다 ㅠㅠ 제길... 오늘 회사 못나갈듯...

놀러나가야 하는데 징징징....

*PS : 멀티큐 블록 레이어에 대한 참고기사 (공개)
*PS2 : BFQ 소개 , Kyber 소개


posted by mirr

댓글을 달아 주세요

Skills/Linuxworld 2017. 2. 26. 00:33

최근 한 2주정도를 계속 게임과 미드에 몰입하던 터라 흥미로운 기사가 몇개 있었음에도 불구하고

그냥 '에이 제껴 어차피 일주일단위로 공개되는데 구지 내가....' 라는 마인드로 넘겨버리고 있었는데...

오늘은 좀 무료한 감이 있더라..(금방 질리는 게임불감증 ㅠㅠ)

그래서 그냥 여러가지 외국 기사들 보며 맥주나 마시던 중 Cgroup 내용이 있어서 살짝 소개하려고 한다.

-----

우리나라의 기라성같은 은둔고수들중에 가장 유명해진(?)
Full time kernel hacker 인 허태준님께서 메인테이너로 개발하고 있는 CGroup 에 대한 내용이라서
내가 실전에서 사용한지 너무 오래되서 가물가물한 지식임에도 불구하고, 다루어 보았다.

현재 커널개발에 대해서 상당히 여러부분에 걸쳐
다양한 변화 및 움직임이 일어나고 있음을 알려주기 위해서이며,
우리나라에선 혁신이란 말을 유행처럼 쓰지만,
외래문화를 바탕으로 두고 있는 사람들- 그냥 외국인 - 의 경우,
정말 필요할 때 자신을 깨부숴 갈 의향을 알리며 사용한다는 말임을
이해해야 한다는 것을 말하고 싶다.

맥주가 다 떨어져서 자야겠.......

원문은 : https://lwn.net/Articles/715051/
- 일주일 뒤 무료공개.

** 엮인글들을 읽어가는 재미가 쏠쏠하다는 점...
*** 태준님 짱이라는...


posted by mirr

댓글을 달아 주세요

Skills/Linuxworld 2012. 5. 4. 17:33

이번주 LWN.net Weekly Issue 의 내용중 가장 흥미로웠다고 할 수 있는 기사는

 

"The Plumbing Layer as new kernel" 이라는 황망한 기사..

 

왠 배관계층??? 이라는 생각이 드는게 먼저인데,

 

일단 이걸 얘기하려면 Plumbing Layer 가 무엇인지에 대해서 설명을 해줘야할거같다.

( 좀 알아서들 찾아보라고!! 나도 꼬부랑글씨라 잘 모른다고!! ㅠㅠ )

 

사실 커널이라는 녀석은 Core Library 와 Sub systems, Window system 등

 

여러가지의 하드웨어를 다루기 위한 Driver 및 그것들간의 문맥전달 등을 위한

 

마치 "배관" 과도 같은 구조로 이루어져 있다.

 

Arichitect 의 관점에서 보여지는게 많아 좀 그렇겠지만, 건축으로 따진다면,

 

모든 것들을 유기적으로 연결 시켜 줄 필요가 있는 "배관" 이 설계상 매우 중요하단것이다.

 

 

가만 생각해보면 DtraceKsplice좀더 뛰어나고 독특하며 앞서가는 기능들

 

먼저 패키징하여 장점으로 내새우는 Oracle Enterprise Linux 나,

 

독자적인 Init 방법을 고수하는 Gentoo 등을 비교해 보았을때,

 

많은 사람들이 착각하기 쉬운 엔트로피의 발생에 대한 비용 측면에서

 

과연 그것들이 싼것일까? 자원의 효율이 더 좋은걸까? 라는 의문을 가져볼 필요가 있을것이다.

 

리눅스의 특징을 잊지 말아야 한다.

 

"다수가 하나이며, 하나가 다수인 무한의 거대한 흐름"

 

야 말로 리눅스의 특징이라고 나는 생각한다.

 

그래서 리눅스 엔지니어라는게 자랑스럽다.

 

원문기사 링크 (일주일뒤에 일반공개됨)

http://lwn.net/Articles/495516/

 

 

posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2012. 1. 1. 14:03
노트북이 켜놓고 당기면 간간히 행업이 되는 경우가 생겨서,

귀차니즘을 무릅쓰고 덤프분석을 오랜만에 시행했다.

뭐 보고싶은사람들만 보도록 :P

Add : 역시 잘 되는것 같다. 커널 업데이트 이후 행업은 없어졌다. :)

커널 덤프분석은 아무것도 아니다.

다만 프로그래밍 그리고 디버깅에 대한 막연한 두려움이 중요한 걸 찾아 낼 수 있는

눈을 흐리멍텅하게 가릴 뿐, 두려움 따위는 벗어던지고, 모르면 공부하면 되는거다.

Add 2 : 기존 커널분석 보러가기 ( Mirr's Springnote )

posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply

    비밀댓글입니다

    2015.08.18 17:21

Skills/Linuxworld 2011. 10. 28. 16:18
한동안 엄청나게 뜸했었나?

IBrix 녀석이 이슈도 많고, 귀찮기도 한데다, LWN 도 어차피 일주일지나면 공개되는녀석이라

구지 이렇게할  필요가 있나 싶어 패스하고 있었는데, 아무래도 나태해지는것 같아서,

다시 시작해 보려고 한다.

일단 2011년 RT Minisummit 이 10월 22일 프라하 ( Prague 라는데 영어식이래 )

에서 열렸다고 한다. - 3일간 개최하며 13번째나 된다고 하네...

( 기사 본문 : http://lwn.net/Articles/464180/ 일주일 후 열람 가능 )

일종의 Realtime (이하 RT) 개발자들 관련하여 워크샵처럼 소규모로 모여 회의하는건가본데,

회의 내용은 다음과 같다.

1. Per-CPU data
2. Software interrupts
3. Upstreaming
4. The Future

이렇게 네가지라는데, 하나하나 살펴보도록 하자. (나도 얕은지식으로 덤벼드는거라ㅠㅠ)


여기까지가 일단 기사의 내용이고,

기사의 내용을 전부 번역하기보단 관심을 갖고 한번 살펴보기 좋을 정도로만

얘기하였다.

Realtime 컴퓨팅에 대해서 아직 충분한 지식을 갖고 있진 않지만,

요즘 상당히 주목받고 있는 부분인건 사실이고,

앞서 얘기했던 높은 처리량과 매우 낮은 응답시간을 어떻게하면

최대한 제공할 수 있을지에대한 노력은 꾸준히 이루어 지고 있는것 같다.

개인적으로 여기서 또 한가지 중요하다고 생각하는 점은 낮은 응답시간과

높은 처리량뿐만아닌, 지속적인 서비스또한 중요하다고 생각한다.

즉, High Throughput - Low Latency - Continues Service 의 삼위일체

궁극적으로 이루어 져야 할 목표라고 본다.

아직 일반 커널조차 제대로 파악하지 못한 상태에서 리얼타임은 그림의 떡일뿐이지만,

언젠간 나도 저들 사이에서 미래를 위해 한마디 할 수 있는 날이 오지 않을까? 안오냐? ㅎ

posted by mirr

댓글을 달아 주세요

Skills/Linuxworld 2011. 5. 19. 21:42
LWN 4월 말 기사인것같은데 이제서야 분석한다. (이제 무료전환 풀렸을듯)
( 원문 : https://lwn.net/Articles/440347/ )

간략하게 요약하자면 Dcache 확장성과 보안모듈에 대한 충돌과정과,

패치전에 제대로 만드는것에 대한 중요성(?) 인데,


마지막 문구에선, 이렇게 Late-Cycle 즉 마지막주기에 패치를 해대는것보다

오히려 초기부터 안전하고 여러가질 고려한 프로그래밍을 했어야 한다는

말로 난 이해했는데....뭐 대강 이런 내용이고,

오역도 있을 수 있어서 본문을 직접 보는게 좋을듯....

dcache 에 대한 내용을 살펴보는것도 좋고, IBM Development Libraries 에도

RCU 등에 대한 좋은 문서들 많이 있으니 참조하시면 좋을듯함...
(아직 기사 세개 더 정리해서 써야.......쿨럭) 

'Skills > Linuxworld' 카테고리의 다른 글

커널 2.8.0 ??  (0) 2011.05.25
Scale Fail - 1 부  (0) 2011.05.23
Dcache scalability and security modules  (0) 2011.05.19
LWN 기사중 커널패치 동향 관련 기사..  (0) 2010.09.20
LWN 기사중 LFCS 관련 기사 -2-  (0) 2010.05.23
LWN 기사중 LFCS 관련 기사 -1-  (0) 2010.05.23
posted by mirr

댓글을 달아 주세요

Skills/Linuxworld 2010. 9. 20. 09:55
흥미로은 LWN 기사중 하나..9월 9일자 위클리이기때문에 지금 아무나 접근 가능할 것으로 본다..

http://lwn.net/Articles/403836/

왜 흥미롭냐면... 난 사실 btrfs 에 관심이 많은 편인데, 외국에서도 아직까진 별로 관심도가 낮나보다..

아니면 뭐...완벽한 셈이거나 ( 하지만 완벽한것 없다라는 주의이므로, 관심도가 낮다고 보는입장.. 쿨럭 )

ext4 의 경우 역시 레드햇 대세이기때문에..게다가 오랫동안 사랑받던 ext3 파일시스템의 후계이기때문에,

더욱 관심 받는듯.... ㅎㅎㅎ

Subsystem Patches Pct
(mainline)(stable)
fs/ext4 216 90 42%
fs/btrfs 155 42 27%
drivers/usb 1003 112 11%
arch/x86 1877 176 9%
drivers/acpi 291 24 8%
mm 602 48 8%
kernel 1471 96 7%
sound 1369 88 6%
fs/ext3 58 3 5%
drivers/scsi 1054 51 5%
net 2324 98 4%
drivers/input 381 13 3%
arch/powerpc 917 18 2%
drivers/media 1705 26 2%
block 182 3 2%
arch/arm 3221 19 <1%
tools 873 3 <1%

mm 에 대한 패치도 이젠 뭐... 거의 완벽한 셈인데다 (사실 더이상 완벽하게 만들 능력자들도 적어진 상태),

건드릴 수 있는 사람들이 거의 없는 상황에서 무려 8퍼센트나 커밋 및 패치 된점은 정말 놀랍더라..

그외 재밋는것들은 acpi 에 대한 패치... 이노무 acpi 는 하드웨어 표준 프로토콜이면서도 계속 패치가 되..

이건 좀 아범이나, HP 등에서 각성해야 하는거 아닐까 싶다능.... 쿠후후

대략 커널 개발자들의 동향이 어느쪽에 집중되어 있는지 구지 말 안해도 알겠지만,

파일시스템이 현재처럼 저장매체의 발달이 급진적인 상황에서,

게다가 정보 저장에 대한 관심이 높아질만큼 많은 정보가 넘쳐나는 세상에서....

당연한 결과이긴 하겠지... :)

나도 파일시스템 개발쪽 하고 싶지만... MM 에 관심이 더 많으면서도,

능력은 이도저도 못낄만큼밖에 안되니... 구경하며 감탄만 할뿐... 흑...

posted by mirr

댓글을 달아 주세요

Skills/System 2010. 8. 6. 17:54
Taint 가 뭐냐면... 뭐 단어는 구글단어장에서 찾아!!!

일단 Kernel 패닉등이 일어나면 코어에 혹은 로그에 관련 로그가 찍히는데,

거기보면 Pid: 15652, comm: scopeux Tainted: P      2.6.9-89.ELsmp 이런게 남는다. 여기에 있는 Tainted다.

대략 정리해보자면 이 상태를 찍어주는 Flag 의 종류는 레드햇의 경우 총 7개가 있다..
(소스보기 귀찮아서 그냥 매뉴얼만 봤다.. 디테일하게 묻진 말자 :P )

1. P: Proprietary License 를 갖고있는 모듈이 문제를 일으켰다는 내용으로 독점적 라이센스를 뜻한다.
   즉 써드파티따위에서 GNU 나 GPL 아래 있는 모듈이 아닌 자체제작된 모둘이라는 것으로 source 코드에
   대한 지원이 불가능함을 뜻한다. 즉 일단 써드파티 모듈부터 까고 봐야 한다는거지!

2. G: 잘 안나오는녀석이긴한데, 이건 말 그대로 GPL 에 영향에 있는 공개된 모듈에서 문제가 됬다는 것이다.
   P 의 반대로 생각하면 된다. 이경우엔 리눅스 커널 개발자가 알아서 해줄지도 모른다 :)

3. F: 강제로 로드된 모듈에서 결국 문제가 발생되어버렸다 라는 뜻으로, insmod 나 modprobe 의 -f 옵션으로
  강제 로드된 모듈에서 버전 정보등의 검사를 하는 도중 커널에 문제를 일으켰다는 내용으로 보면 된다.

4. R: 커널이 운영되고 있는 중에, 그리고 사용중인 모듈인데 강제로 (rmmod -f 옵션) Unload 시켰을때
  발생하는 플래그이다.. 결국 뻘짓거리 하지말고 정상적으로 사용하라는 것...

5. S: SMP 커널을 사용할때 CPU 할당 관련 문제시 발생하는 플래그이다.

6. M : MCE ( Machine Check Exception ) 에서 일으키는 문제에 대한 플래그로, CPU 온도가 높다던가,
  메모리 뱅크 및 슬롯이 잘못됬을때 하드웨어에서 감지하고 일으키는 문제에 대한 플래그.

7. B: Bad Page State 를 뜻하는 것으로, 리눅스가상메모리(virtual memory) 에서 잘못된 부분을 감지했을때
  사용되는 플래그이다. 보통 RAM 또는 메모리 캐쉬의 문제시 발생되곤 한단다..

자...7개다.. kernel Document 보면 사실 한 3개쯤 더 있는데, 난 7개만 썼다.. 왜?

오래된 문서를 보고 정리한거고, 커널문서에서는 tainted 에 대한 비트수만 나와있지 뭐라고 찍히는지는

안나아욌어서다... 짜증나게 깊이 묻지 말자... :)

대략 tainted 에서 뜨는 내용만 보고도 어디를 조져야 할지 나온다. 좀 이런것좀 보면서 일하잔 말이다! ㅠㅠ

어만 리눅스만 자꾸 잡아대려고 하지 말고!

근데 나 이거 열심히 쓰고 봤더니 예전에 내가 정리해서 쓰지 않았던가 라는 데자뷰현상이!!!!

블로그 뒤지다보면 간간히 예전에 썼다 생각했는데 없는것들이 있다...

뭐지.. 나 해킹당하나 머릿속 해킹... :(


posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply Favicon of http://ydhoney.egloos.com BlogIcon ydhoney

    이 분 늪에서 빠져나오기는 글렀구만..(...)

    2010.08.31 16:39

Skills/Linuxworld 2010. 5. 23. 23:51
아까 노인들만 늘어난다(?) 라는 내용 외에 또 한가지 흥미로웠던것!

바로 구글과 안드로이드다!

( IBM 관련 대화들도 있긴한데 개발관련 된 부분들과 10주년 키노트 관련부분이라 그냥 패스한다.. )

Chris DiBona ( Google's Open Source Program Manager ) 의 대화가 있는데,

한동안 구글은 오픈소스 개발자들의 블랙홀이라는 비난을 받을 만큼 오픈소스 개발자들을 자꾸 대리고가서는

감옥에 가둬놓고 다른일은 전혀 못하게 착취를 시키곤 했는데(응~?)

크리스는(크리스맞나?) 구글이 오픈소스에 기여하는 점이 얼마나 많은지 설명하며 비난아닌, 상을 받아야

한다고 주장했었다고 한다.
(뭐 code.google 에 있는 3만개 이상의 코드들이라든가, 지들이 내는 패치 뭐 기타 등등등 )

재밌는건 내용 대충 보면 구글진영의 발언은 분노만 샀다는점 ㅎㅎ

안드로이드에 관해서 그는 upstream 에 merge 를 위해 그 과정과 온갖 관심들을 즐겁게 견딜 수 있을 만한

매조히즘을 갖고 있는 매조키스트 개발자가 없어서 어쩔 수 없다라고 한 발언이 있었다.

즉, 메인라인에 안드로이드를 포함하기 위해서 복잡한 메인라인 머지 작업과, 리뷰어들의 비난,

패치요청에 대한 작업을 구글 내부에서 막거나 규제하고 있진 않지만, 그것 자체에 대한 부담을 이겨내고

선뜻 나서서 진행하는 사람이 전혀 없다는 점....(이점은 예전기사들 보면 잘 나와있다 나중에 정리함 할까..)

즉, 당분간은 구글이 직접 나서서 커널 메인라인에 포함되는 일은 어렵고, 하고싶지 않다는 얘기 ;(
(예전에 욕 대지게 먹고 메인라인에서 쫒겨났었.... :P )

어쨋든 그 발언을 비롯하여 비난을 샀으면 샀지 그가 생각했던 만큼의 칭찬과 찬사는 얻어가지 못해

실패한 발언이였다고 전하고 있으며, 정말 흥미롭고도 너무 부럽게도, 이 성공적이지 못한 발언커버를 위해

세션 참석자 전원에게 "Nexus One" 을 주었다는 것!!!!!!! (ㅠㅠ 이런데 가고싶다 가고싶다 젠장 영어 ㅠㅠ )

이것으로 많은 비난의 소리를 잠재울 수 있었더라는 얘기가 있다 :)

이것으로 충분히 만족스러운것 아닌가!!! 핸드폰을 그냥 막 뿌려줄 수 있을 정도의 배포!! 구글사마 ㅠㅠ

세션 후 조나단 코뱃 (기자다) 이 따로 안드로이드 커널 개발자들을 만났고,

이들의 얘기는 크리스의 말과는 달랐다고 한다.

이들은 여느 임베디드개발자와 동일 하였으며, "우리나라" 에서 역시 "흔히들" 말하는 식으로,

"언제나 상품 개발 주기는 짧고, 시간은 부족하기때문에, 커널 메인라인에 merge 를 할 엄두가 없다"

라고 했다는 것이다.

안드로이드 커널 개발자들은 점점 외톨이가 되어 가며, 그것이 그들을 좌절시킨다고 기사에서 전하고 있다.

조나단은 이 기사를 통해 안드로이드 커널 개발자들이 모든 리눅스 커뮤니티에서 그들과 소통하려고

하였던 모든 요구들을 잘 들어왔고 충분히 이해하고 있다고 말하며,

이번 기회를 통해 그들의 참여를 너그럽게 충분히 도와줘야 하는 시점이라고 말하고 있다.

우리 회사에서도 현재 안드로이드 개발을 열심히 연구중이곤 한데, 그들중에 실제 커널 개발 및

리눅스 커널에 대해서 얼마나 깊은 기여의식과 관심이 있을지 모르겠다....

아마 "우리나라" 에서 "흔히들" 말하는 시간이 없고, 상품개발 주기가 짧다는 말은,

외국에서 쓰는 말과는 다르지 않을까 싶다.

우리나라는 마인드와, 기본기를 충실히 닦아가려는 자세부터 고쳐먹어야 할 것이다. ;(

난 아직 안드로이드 커널에 대해서 이렇다할 입장은 표명 할 수 없다. (잘 모르기에 ㅠㅠ )

사실 MeeGo 가 더 땡긴다 :P


PS : 고작 한개 기사 정리하는데 주말을 다 보냈다.. 정말 세상과, 시간, 그리고 우주는 끊임없이
       팽창해 가고 있고, 나에게 주어진 삶이라는 시간은 계속 타들어가는 촛불과 같다.
       그리고 나라는 그 촛불이 꺼질 시기는 온 몸이 다 타들어간 뒤이다.

다음 기회때는 TSC (Time Stamp Counter) 나 SLEB 에 관해서 (좀 간단한편이라 ㅠㅠ)

얘기해 보도록 하겠다.. 그럼 모두들 스윗쥬림 (Sweet Dream~)
posted by mirr

댓글을 달아 주세요

Skills/Linuxworld 2010. 5. 23. 23:13
그동안 LWN에 흥미로운 기사들이 무쟈게 떴었는데,

귀차니즘과 먹고사니즘때문에 계속 헤드라인정도만 확인하고 시간이 흘러버렸었다..

지금 아직 번역중인것도 있고, 번역은 완료 했는데, 내용정리가 안되있는것들 몇가지 있긴하지만,

차츰차츰 올릴 예정이고, 일단 지금은 샌프란시스코에서 열린 LFCS 에 관한 기사이다.

뭐 왜 흥미로웠냐면, Graybeards (내용 상 의미로하자면 노땅이라고 해야 할려나 ㅠㅠ) 에 관한 부분인데,

사실 현인이나 고수, 고참파일럿을 뜻하는 단어인데,

기사내용에 의하면 요즘 커널 개발자들의 새로운 피가 수혈되지 않아 어찌 해결해야 할지에 대한토론이다.

링크를 걸었기 때문에 보면 재밌을 것이라고 생각한다 :)

대략 결론만 요약하자면 커널 개발자의 노령화가 진행되고 있는것 같아 보이지만 실재론 그렇지 않다는 것.

매 커널 릴리즈 주기마다 1000명 이상의 개발자들이 참여하게 되며,

그 중의 상당 부분이 처음으로 릴리즈에 공헌 (constribution) 하는 사람들로,

그중 약 20%정도는 페이에 상관 없이 스스로, 그리고 취미로 contribution 을 즐기는 사람이라고 말하며,

오히려 contributor 중 일부는 다른 프로젝트에 참여하게 하는것이 차라리 나을 것이라는 얘기까지

돌고있을 정도로 많은 개발자들이 충원되어 발전하고 있다는 것이다.

내가 알기로도, 단순한 패치를 올리고 리뷰하는 코더들은 물론 릴리즈까지 직접 관여하여 각 부분별

프로젝트에 참여하고 있는 개발자들이 너무나도 많아 커널 릴리즈 속도가 엄청 빨라진걸로 알고 있는데..

여기 새로운 커널 개발자들이 너무 없다라고 했던 링크된 기사에서 새로운 피가 수혈되지 않는 이유가 있다.
 ( http://www.jfplayhouse.com/2010/04/why-linux-is-not-attracting-young.html )

링크에 의하면 신선한 피들의 수혈이 안되는 이유로 Linux 가 이미 기업소속개발자 들의 주도로

발전되고 있으며, 이로 인해 개인이 취미로 활동하는 부분들에서 얻을 수 있는 만족감이 크지 않다는 것이다.

이거 우리나라에서 쓴건가 라는 생각을 할정도로 재밌는 기사였다 :)

하지만 난 좀 다른 이유로 본다.

메인라인 커널 커뮤니티에서는 대부분 각각의 분야가 있다.

서로가 각각 맡은 분야에 집중하다 보면 충분한 만족할 수 있다고 생각한다.

실재로 난 아직 커널 메인라인에 기여할 만큼 코드를 리뷰하거나 패치하지 않고 있고 실력도 안된다.

오픈소스 경험이라고는 골랑 vsftpd 와 tar, apache 에 아주아주 소소한 그것도 메일 보냈으나,

필요없을것 같아 포함하진 않겠으나 감사하다 따위의 메일정도만 받아 봤을 뿐...

개인별로 어느 정도의 기여를 해야만 자신이 그 프로젝트에 참여하고 있으며,

자랑스럽다고 느낄 수 있을지 모르겠지만,

그 메일 조차 나에게는 감격이였으니까.....

하지만 반면에, 이미 돈을 받으며 메인라인에 참여하고 있는 풀타임 개발자들의 비중이

대하고 중요하다는 것은 사실이고, 전체적으로 따져 보았을 때 필요한 부분이기 때문에

Linux 가 더 발전되고 퍼져나가는 것이라고도 생각한다. (왠지 내가 그냥 뿌듯 ㅠㅠ)

리눅스 개발의 진입장벽에 대한 또 다른 시각도 있었다.

커널 코어 개발자들의 경험치가 높아지는 반면 더 복잡한 코드가 포함되고 있다는 내용...

이로 인해 커널 개발의 진입장벽이 덩달아 높아지고, 그로 인해 코드 유지보수 역시

계속되서 어려워질 것이라는 이슈가 있다.

사실 개발자가 없는 이유를 들자면 난 이 말에 손을 들어 공감한다.

지금 리눅스 커널은 예전 한참 공부했던.. 시작하던때와 완벽하게 달라졌다.

feature 및 모듈들은 계속 증가하고, 변화하며 제거되고 있으며,

IT 산업자체의 흐름에도 맞추어 가야 하기 때문에, 쉽게 말해 짜바리들은 꺼져 가 되는 것이다.

"너 커널 개발 참여하고 싶으면 이거부터 알고와..." 라고 해서 조낸 공부하다보면

이미 커널은 저~~ 멀리 달아나있다. 당장 어디서부터 시작해야 할 지 모를 정도로 멀리 와버린 것이다.

"응 나 그냥 무작정 걷다보니 지구를 얼마나 돌았는지 모르겠네..선그어논거 있으니 쭉 그거 따라오면서

몇바퀴 돌았는지 세어보면 알꺼야" 라는....

몇년 전가지 커널 책들은 아직도 한참 옛날 커널들에 맞추어진 책들만 쏟아져 나왔었고,

현재 변화된 커널에 맞는 개발에 대한 양서를 찾기란 매우 어려운 상황이 되어버렸다.
( 심지어 시스템엔지니어를 위한 서적들은 아직도 레드햇 9계열이다 !!! )

무엇보다 이 커널 변화동안의 갭을 채워줄 훌륭한 서적들이 절대적으로 부족하다는 점...

물론 참여하기 위해 외국놈들에게 마구 물어보면 git 와 kernel source 에 있는 주석들 그리고 문서들을

이용하면 충분하다고 답해주고, 실제로 투덜대며 보면 잘되있다라는 게 요즘 그나마 다행이라는 점이다 ㅠㅠ

요즘은 또한 커널개발 책들도 괜찮은 것들이 보이긴 한다..

모 고객사 커널레벨 이슈로 인해 커널에 대한 관심을 깊히 가지게 된 뒤로 계속 행동하진 못하고 있지만,

이번 기회에 정말로 최대한 참여해 봐야 겠다는 생각을 할 수 있었다.

일단 커널 공부를 위한 계획을 세워야 하고, 어떻게 어디서부터 시작해야 할지를 정해야 겠지....
( 어디 사부라도 있으면 정말 도시락 쌓들고 당기면서 배우고 싶은 심정 ㅠㅠ )

나도 나름 커널개발의 젊은(응~?) 피 가 될 수 있을까... 도전해 볼 과제다..(응?)

posted by mirr

댓글을 달아 주세요