Linux Kernel(4.19) Hacks

rousalome.egloos.com

포토로그 Kernel Crash


통계 위젯 (화이트)

230224
1178
109352


임베디드 리눅스 개발자 양극화를 극복하는 방법: 리눅스 커널 메일링 리스트 활용 임베디드 에세이

제가 올린 포스팅 중 생각지도 않게 조회수가 높게 나올 때가 있습니다. 그 중 하나는 다음 포스팅입니다.

댓글을 보면 알 수 있듯 많은 분들이 공감해주셨습니다. 

   * 맞다! 임베디드 개발의 양극화는 정말 심하다!

그런데 전 이글을 올린 후 리눅스 세미나에서 다음과 같은 질문을 받았습니다.

   * 임베디드 개발의 양극화가 심하다는 것은 알겠다.
   * 그런데 그 해결책은 무엇이냐?

이 질문을 받고 바로 전 다음과 같이 대답을 했습니다.

   * 출간될 제 책을 사보세요.
   * 제 책이 임베디드 양극화의 Gap을 줄여 줄 수 있을 것이라 생각합니다.

농담 반, 진담 반으로 드렸던 대답이었습니다. 그런데 돌이켜보니 정말 *헛소리*를 했단 생각이 듭니다.
그래서 시간을 갖고 조금 더 곰곰히 고민해 봤습니다. 

   * 임베디드 리눅스 개발의 양극화를 극복하는 방법은 무엇일까?

이번 포스팅에서는 '임베디드 리눅스 개발의 양극화를 줄이는'이 방안에 대해서 조금 이야기해보려고 합니다.

리눅스 커널 메일링 리스트란 무엇인가? 

제 블로그에서 언급했지만 임베디드 리눅스는 다음과 같은 여러 단체가 협업한 결과물입니다.

   * 리눅스 커널 커뮤니티 + CPU 벤더(인텔, ARM, AMD) + SoC(퀄컴, 삼성 LSI, 브로그컴)

여러분이 어떤 임베디드 리눅스 제품을 개발하던 위 단체의 결과물과 연관이 돼 있는 것입니다.
그런데 이 단체 중 핵심은 어디일까요? 정답은 '리눅스 커널 커뮤니티'입니다. 아무리 CPU벤더나 SoC 업체가 노력한다고 한 들 리눅스 커널이 없으면 무용지물일 것입니다.

   * 리눅스 커널 커뮤니티란 무엇일까요?

'리눅스 커널 커뮤니티'는 리눅스 커널 개발자들이 메일로 패치를 주고 받고 치열하게 토론하는 포럼입니다. 주로 다음과 같은 주제로 열띤 토론을 벌입니다.

   * 각 리눅스 세부 기능(Subsystem)별로 버그 공유
   * 새로운 기능에 대한 논의 
   * 질문과 대답 
   
자, 이 부분을 읽으니 이어서 다른 의문이 생깁니다.

   * 이런 논의를 어디서 할까요? 카카오톡 같은 메신저로 대화를 할까요?

아닙니다. 리눅스 커뮤니티에서 커널 개발자들은 '리눅스 커널 메일링 리스트'를 통해 서로 의견을 주고 받습니다.
리눅스 커널 메일링 리스트는 누구나 등록할 수 있으며 리눅스 커널 개발자들이 주고 받은 '토론'을 여러분도 그대로 받아 볼 수 있습니다.

리눅스 메일링 리스트로 어떤 내용을 알 수 있는가? 

리눅스 커널 메일링 리스트를 통해 다음과 같은 내용을 알 수 있습니다.

   * 리눅스 커널 개발자들이 작성한 패치 코드
   * 커널 크래시나 락업에 대한 리포트 및 해결 패치
   * 리눅스 커널 개발자들의 토론 내용

리눅스 메일링 리스트를 활용해 정상급 커널 개발자에게 질문하기

그런데 여러분이 리눅스 커널 메일링 리스트를 통해 커널 개발자가 토론하는 내용을 읽다 보면 여러가지 궁금한 점이 생길 수 있습니다. 이 때 어떻게 하면 될까요? 

   * 메일링 리스트나 해당 개발자에게 질문을 하면 됩니다.

그러면 한 가지 예를 들어볼까요? 제가 커널 메일링 리스트를 구독해 읽던 도중 다음과 같은 메일을 받았습니다.
[PATCH] usnic: avoid overly large buffers on stack

It's never a good idea to put a 1000-byte buffer on the kernel
stack. The compiler warns about this instance when usnic_ib_log_vf()
gets inlined into usnic_ib_pci_probe():

drivers/infiniband/hw/usnic/usnic_ib_main.c:543:12: error: stack frame size of 1044 bytes in function 'usnic_ib_pci_probe' [-Werror,-Wframe-larger-than=]
...
diff --git a/drivers/infiniband/hw/usnic/usnic_ib_main.c b/drivers/infiniband/hw/usnic/usnic_ib_main.c
index 03f54eb9404b..c9abe1c01e4e 100644
--- a/drivers/infiniband/hw/usnic/usnic_ib_main.c
+++ b/drivers/infiniband/hw/usnic/usnic_ib_main.c
@@ -89,9 +89,15 @@ static void usnic_ib_dump_vf(struct usnic_ib_vf *vf, char *buf, int buf_sz)

 void usnic_ib_log_vf(struct usnic_ib_vf *vf)
 {
-       char buf[1000];
-       usnic_ib_dump_vf(vf, buf, sizeof(buf));
+       char *buf = kzalloc(1000, GFP_KERNEL);
+
+       if (!buf)
+               return;
+
+       usnic_ib_dump_vf(vf, buf, 1000);
        usnic_dbg("%s\n", buf);
+
+       kfree(buf);
 }

 /* Start of netdev section */

패치 코드 내용은 다음과 같습니다. 

   * 지역 변수 배열로 1000-byte 로 할당하면 '프로세스'의 스택 공간을 많이 써서 좋지 않다.
   * 지역 변수 배열 대신 동적 메모리를 할당해 메모리를 할당한다.
   * 결국 프로세스 스택 오버플로우를 방지할 수 있다.

아주 훌륭한 패치 코드란 생각이 들었습니다. 그런데 이 내용을 읽고 전 한 가지 의문이 생겼습니다. 

   * 어떻게 이런 사실을 알게 됐을까?

그래서 직접 이 패치를 작성한 개발자인 'Arnd Bergmann' 님께 메일로 질문을 했습니다.

Hello, Arnd Bergmann

I took a look at your patch which seems to be very practical.
I am sure that your patch might avoid _potential_ stack overflow where
callstack is very deep.

My question is
  'how did you find out this problem?'
void usnic_ib_log_vf(struct usnic_ib_vf *vf)
 {
-       char buf[1000];
-       usnic_ib_dump_vf(vf, buf, sizeof(buf));

Did you just have a code review in details? Or run a program-tool?
If you have some time, please give me a tip.

Thanks in advance.
Austin Kim

'Arnd Bergmann'님은 Linaro에 소속된 정상급 커널 개발자입니다. 떨리는 마음으로 메일을 보냈는데 5분 후 답장이 왔습니다.

> My question is
>   'how did you find out this problem?'
> void usnic_ib_log_vf(struct usnic_ib_vf *vf)
>  {
> -       char buf[1000];
> -       usnic_ib_dump_vf(vf, buf, sizeof(buf));
>
> Did you just have a code review in details? Or run a program-tool?
> If you have some time, please give me a tip.

This is a normal compile-time warning that happens on 32-bit architecutres,
you probably see it when building a x86-32 allmodconfig kernel
using "make ARCH=i386 allmodconfig ; make -skj16 '.

I found it while building random configurations using 'make randconfig'.

The compiler I used is clang-9, but it probably also happens with
most gcc versions. On 64-bit machines, we currently only warn
for stack frames larger than 2048 bytes, on 32-bit the limit is 1024.

와우, 정말 친절한 설명이었습니다. clang-9을 써서 다음과 같이 커널을 빌드했더니 WARN(경고) 메시지를 확인했다는 것입니다.

   * make ARCH=i386 allmodconfig

전 이메일을 받고 'Arnd Bergmann'님께 다음과 같이 간단히 답장을 보냈습니다.
Thanks for the tip! 

이렇게 리눅스 커널 개발자에게 직접 질문을 하고 대답을 들 을 수 있었습니다.

정리

이전 포스팅에서 언급한 바와 같이 임베디드 개발자의 양극화의 원인은 다음과 같다고 설명을 드렸습니다.

   * 실전 개발을 통해 실무를 배울 수 있는 기회 박탈 

그런데 리눅스 커널 메일링 리스트를 통해 다음과 같은 기회를 얻을 수 있습니다.

   * 정상급 리눅스 커널 개발자들의 토론
   * 정상급 리눅스 커널 개발자에게 질문하고 답을 들을 수 있음

여러분 주위 선배 실력이 형편없고 배울 수 있는 것이 없다고 불만이 생길 수 있습니다. 하지만 리눅스 커널 메일링 리스트를 활용하면 정상급 개발자와 소통할 수 있습니다.

리눅스 커널 메일링 리스트를 잘 활용해 유익한 내용을 얻기를 바랍니다.



핑백

  • Linux Kernel(4.19) Hacks : 임베디드 개발자 양극화는 얼마나 심각할까? 2019-09-21 18:31:15 #

    ... 사하겠습니다. 그리고 혹시 궁금점이 있으면 댓글로 질문 남겨주세요. 상세한 답글 올려드리겠습니다!" # 관련 글임베디드 리눅스 양극화를 극복하는 방법: 리눅스 커널 메일링 리스트 활용 한국 개발업체에서 절대 리눅스 전문가가 될 수 없는 이유(1) - SW문화한국 개발업체에서 절대 리눅스 전문가가 될 수 없는 ... more

  • [Linux Kernel(4.19) Hacks] 임베디드 리눅스 개발자 양극화를 극복하는 방법: 리눅스 커널 메일링 리스트 활용 - DEVBLOG - 개발자 메타블로그 2019-09-22 00:17:37 #

    ... Kernel(4.19) Hacks] 임베디드 리눅스 개발자 양극화를 극복하는 방법: 리눅스 커널 메일링 리스트 활용 원문 링크 임베디드 리눅스 개발자 양극화를 극복하는 방법: 리눅스 커널 메일링 리스트 활용 미리보기 제가 올린 포스팅 중 생각지도 않게 조회수가 높은 글이 종종 있습니다. 그 중 하나는 다음 포스팅입니다. 임베디 ... more

  • Linux Kernel(4.19) Hacks : 기생충같은 관리자들 2019-09-26 08:19:26 #

    ... 것이다. 그 시간에 차차리 코드나 로그를 좀 더 분석할 것이다. # 관련 글 임베디드 개발자 양극화는 얼마나 심각할까?임베디드 리눅스 개발자 양극화를 극복하는 방법: 리눅스 커널 메일링 리스트 활용한국 개발업체에서 절대 리눅스 전문가가 될 수 없는 이유(1) - SW문화 한국 개발업체에서 절대 리눅스 전문가가 될 수 ... more

덧글

댓글 입력 영역