KVMALLOC()

memory = kmalloc(allocation_size, GFP_KERNEL);
    if (!memory)
        memory = vmalloc(allocation_size);

kvmalloc() 은 내부적으로 kmalloc() 호출을 시도한다. 이는 slab allocator 를 이용한 메모리 압박이 없다면 빠른 메모리 할당을 지원한다. 또한 slab 은 PAGE_SIZE(32비트에서는 4KB) 보다 작은 메모리 할당을 위해 사용하고, 그보다 큰경우에는 물리적으로 연속적인 메모리를 할당하려고 한다. 하지만, 시스템을 운영하다 보면, 할당할 수 있는 메모리 공간은 있지만, 단편화로 인해 물리적으로 연속적인 공간은 할당 받지 못하는 경우가 있다. 물론, 연속적인 공간 확보를 위한 compaction 등의 feature 로 노력은 하지만 연속적인 공간 요청이 크다면 힘들 수도 있다.

 이런 경우 가상주소 공간에서 연속적인 메모리 할당을 vmalloc() 으로 가능하게 한다. vmalloc() 은 가상 주소 공간에서 연속적이지만, 실제 물리적으로는 흩어진 메모리를 관리한다. 이런 할당은 페이지 테이블의 수정이 생기고, TLB cache 의 invalidation 을 갖게 된다.(페이지 폴트) 또한 PAGE_SIZE 보다 작은 메모리 할당은 align 되어 PAGE_SIZE  만큼 할당할 것이다.

 이제 kvmalloc() 내부를 보자.

/**
 * kvmalloc_node - attempt to allocate physically contiguous memory, but upon
 * failure, fall back to non-contiguous (vmalloc) allocation.
 * @size: size of the request.
 * @flags: gfp mask for the allocation - must be compatible (superset) with GFP_KERNEL.
 * @node: numa node to allocate from
 *
 * Uses kmalloc to get the memory but if the allocation fails then falls back
 * to the vmalloc allocator. Use kvfree for freeing the memory.
 *
 * Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL are not supported. __GFP_REPEAT
 * is supported only for large (>32kB) allocations, and it should be used only if
 * kmalloc is preferable to the vmalloc fallback, due to visible performance drawbacks.
 *
 * Any use of gfp flags outside of GFP_KERNEL should be consulted with mm people.
 */
void *kvmalloc_node(size_t size, gfp_t flags, int node)
{
    gfp_t kmalloc_flags = flags;
    void *ret;

    /*
     * vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables)
     * so the given set of flags has to be compatible.
     */
    WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);

    /*
     * Make sure that larger requests are not too disruptive - no OOM
     * killer and no allocation failure warnings as we have a fallback
     */
    if (size > PAGE_SIZE) {
        kmalloc_flags |= __GFP_NOWARN;

        /*
         * We have to override __GFP_REPEAT by __GFP_NORETRY for !costly
         * requests because there is no other way to tell the allocator
         * that we want to fail rather than retry endlessly.
         */
        if (!(kmalloc_flags & __GFP_REPEAT) ||
                (size <= PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER))
            kmalloc_flags |= __GFP_NORETRY;
    }

    ret = kmalloc_node(size, kmalloc_flags, node);

    /*
     * It doesn't really make sense to fallback to vmalloc for sub page
     * requests
     */
    if (ret || size <= PAGE_SIZE)
        return ret;

    return __vmalloc_node_flags(size, node, flags);
}
EXPORT_SYMBOL(kvmalloc_node);

 void *kvmalloc(size_t size, gfp_t flags);
 void *kvzalloc(size_t size, gfp_t flags);
 void *kvmalloc_node(size_t size, gfp_t flags, int node);
 void *kvzalloc_node(size_t size, gfp_t flags, int node); 

 커널 코드를 보다가 이 헬퍼 함수로 교체 가능한 코드가 있다면 수정 하면 좋겠다.

Beginner Guide to Linux Kernel Hacking

막상 kernel 에 관련된 책도 보고 어떻게 개발에 참여할 수 있는지 고민만 많이 하지 딱히 문제가 있는 부분을 찾는 것도 수정하는 것도 어렵다.(다 잘되어 있는 code 처럼 보이기도 하고 ^^)

이래 저래 초보자(?)를 위한 blog 나 site 를 찾아봤지만 뭘 해야하는지 콕 찝어 얘기해주는 것도 아니고..

암튼, 이 제목을 가진 글은 조금 쉬운 접근 방법인 것 같기도 하고 번역도 쉬울 듯 하여 시작해본다.

시작.

Linux kernel 은 굉장히 복잡한 software 이며 누구나 참여가능하지만 hacking 을 쉽게 하고 개발에 기여하기는 어렵다. 다른게 얘기하면 하루 이틀만에 시작하여 hacking 할 수 있는 것은 아니라는 것이다. 개발자는 kernel 에 대한 지식이 필요한데 모든 kernel 내부는 배울 수 있다는 점이 장점이다.

간단한 kernel 에 대한 note 가 있는데 The workings of the Linux kernel 를 참조하면 된다.(이부분도 번역을..)

개발자 스스로 질문을 해보자, kernel 이 나에게 있어 완벽하게 동작하고 내가 고칠 수 있는 부분은 있는 것인가?

(내가 하고 싶었던 질문이다.) 여기 blog 에서는 이런 부분에 대해서는 미리 단념할 필요가 없다고 한다. 커널 개발자들은 도움이 필요한 상세한 list(정리가 필요한 무수한 code들) 를 갖고 있다. 예를 들어, 이런 code들은 /drivers/staging 디렉토리 내부에서 찾을 수 있다. 이 디렉토리 내부에 있는 driver 들은 일반적인 linux kernel coding guideline 을 만족하지 못하는 code 들이 많다. 여기에 위치한 code들은 다른 개발자들에 의해 mainline 에 merge 되기 전에 정리를 도움받고자 하는 것이다. staging 디렉토리 하위에 있는 모든 driver 는 TODO list를 갖고 있는 것도 참고하면 좋다고 한다.

여기 driver 들의 대부분이 그것들의 TODO list 에 다음과 같은 line을 갖고 있다:

- fix checkpatch.pl issues

이것은 어떤 의미를 가지며 어떻게 해야 하는지에 대한 의문이 있을 것이다. 모든 큰 code 의 내용은 여러 개발자들이 참여하여 개발하기 위한 일정한 coding rule 을 갖고 있다. 어떤 kernel 개발자의 목표는 다른 개발자들에게 code의 error를 찾도록 도움을 받고 싶어 한다. 이런 coding rule 은 이런 error를 찾는 것에 도움을 줄 수 잇다는 것이다. 그래서 kernel 에 code가 들어가기 전에 적어도 두명의 개발자가 code에 대한 review 를 하기 때문에 이런 coding style guildline 은 매우 중요한 덕목(?)이다. 그리고 개발자는 kernel source tree 에 Documentation/CodingStyle 에서 관련 사항을 볼 수 있다. coding style 및 error를 빨리 찾기 위해 scripts/checkpatch.pl 이라는 것이 개발되어 졌고, 기본적이 coding style 이 지켜지지 않아 다른 개발자들의 시간을 낭비하는 일을 줄여주는 역할을 해준다.

암튼, drivers/staging 에 위치하는 driver 들은 거의 항상 styling issue 를 갖고 있을 것이다.(guildline 에 익숙치 않은 개발자가 개발하는 경우가 있기 때문이다.) 일단 처음으로 해볼 것이 이런 것들을 kernel coding style guildline 에 맞춰 수정해주는 것이다. 그래서 처음 시작하는 kernel 개발자는 checkpatch.pl 을 수행하고 관련사항을 수정해주므로 해서 도움을 줄 수 있다는 것이다.

Specific Coding Rules

Documentation/CodingStyle 에 모두 나와있지만 개발자가 시작하는데 있어 간략한 부분을 overview 한다.

Whitespace

대부분이 code를 개발함에 있어 indentation(들여쓰기)를 space 가 아닌 tab 을 사용한다. tab은 대게 8 의 길이의 space 를 갖는다. (kernel code 는 tab 을 space 가 아닌 하나의 tab 문자-4 or 8길이의-를 사용한다.) 커널 code를 보고 tab 이 어떻게 되어 있는지 맞춰 주면 될 듯 하다. 또한 한 line 을 80자 이상 넘겨서는 안된다. 80자는 개발자들이 logic을 더 작고 쉽게 인지 할 수 있도록 도와준다.

Braces

Brace 의 사용에 대한 rule 은 꾀 까다롭다. brace를 여는 것은 한 문장의 마지막에 붙여서 쓰고, brace를 닫는 것은 마지막 문장의 다음 line 으로 넘어가서 사용한다. 예제를 보자    if (error != -ENODEV) { foo(); foo2(); }

만약 if else 문의 구조라면 다음고 같이 한다.

위와 같이 수정 가능하다.

그럼 제대로 수정이 되었는지 확인하면,

$ ./scripts/checkpatch.pl --file --terse drivers/staging/bcm/Qos.c | grep 821

해서 아무런 message 도 나오지 않으면 성공한 것이다.

수정 후, build 해서 확인 해야 한다.

빌드 방법은 다른 site 에서 찾아 보면 된다.

간단히 그 파일만 빌드 하는 방법을 보면, 물론 full build 가 되어있다는 것을 가정하는 것이다.

$ make drivers/staging/bcm/Qos.o

만약 위와 같이 해서 error 발생하지 않는다면, 변경사항을 patch로 만들고 적용가능한 상황까지 만든 것이다.

일단 이것까지 해왔다면 kernel을 download 받았다는 것이지만, 간략하게 kernel 을 받고 patch를 만들고 전달하는 과정을 적어본다.

// 참고로 /path/to/linux/kernel은 아무대나 kernel이라는 directory를 만들면 된다.

$ mkdir /path/to/linux/kernel

$ cd /path/to/linux/kernel

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

준비 되었다면 다음 단계로 넘어간다.

수정을 한 상태라면 git 을 이용해 local commit 을 만들고 그것을 patch set 으로 변환한 뒤, 관계자(?) 에게 review 메일을 보내면 된다.

commit 을 어떻게 했는지 확인해 보자.

$ cd drivers/staging/bcm

$ git log Qos.c

맨 위의 commit 을 보자

patch 만드는 방법은, 

수정 완료 후,

$ git add drivers/staging/bcm/Qos.c

$ git commit 

하면 당신의 editor로 comment 를 입력받는 화면이 나온다.

// image

위에 처럼 comment 를 달고(영어를 못하니 일단 대충..) 저장하면 된다.

첫번째 line은 수정사항에 대한 제목 같은 것을 적고 추가적으로 적으려면 새 line(엔터)을 두개 넣고

적으면 된다. 참고하여 위의 commit 처럼 만든다.

Signed-off-by : Your Name <youremail@email.com> 을 추가한뒤 저장.(저는 안했음. 지금 보낼것이 아니라서..)

이제 당신의 첫번째 patch를 완성했다.

Getting Your Change into the Kernel Tree

위에서 수정한 사항을 patch로 만들어 커널 개발자에게 review 및 전달을 요청해야 한다. 일단 patch를 일단 만들어 보자.

$ git log

당신의 commit 이 제일 위에 있을 것이다.

바로 밑에 있는 commit 의 hashid 를 parameter 로 넣어준다.

$ git format-patch <hashid> -o ~/

이렇게 하면 만들어진 commit 이 0001-XXX.patch라는 이름으로 만들어 진다.

이것을 다시한번 checkpatch.pl 을 수행해서 정상적으로 반영가능한지 확인을 해보자.

내가 위에서 했던 수정했던 것은 또다른 문제를 갖고 있어 error를 출력했지만 정상적으로 되었다면

total :0 errors, 0 warnnings, XX lines checked 가 보일 것이다.

이제 메일을 보내보자.

Now to Send it Off

이제 완정된 patch를 누구에게 보내야 하는지 알아야 한다. 커널 개발자들은 script 로 누구에게 알려야 되는지 쉽게 알수 있다. 그 script는 get_maintainer.pl 이고 이것은 scripts directory에 위치한다. 이 script는 파일을 확인하고 내가 수정한 파일이 kernel source tree의 maintainer 들에 대한 정보를 알려준다. 

$ ./scripts/get_maintainer.pl /path/to/0001-your-patch.patch

devel@driverdev.osuosl.org (open list:STAGING SUBSYSTEM)

linux-kernel@vger.kernel.org (open list)

위와 같이 나오더라.

이것은 일반적인 e-mail client 로 전송하면 patch format에 space및 tab 등 변형이 되기 때문에 Documentation/email-clients.txt 를 확인하여 그 email client 를 이용하여 전송하면 된다. 하지만 git commit 로도 지원이 되는데, 그 방법은,

$ git send-email -to email@email.com -to email2@email.com -cc devel@driverdev.osuosl.org -cc linux-kernel@vger.kernel.org 0001-your-patch.patch 하면 된다.

사실 to 를 누구로 해야하는지는 안나와 있어서 나중에 내가 용기가 나면 시도 해보고 다시 알려주겠다.

또 한가지 git send-email command 가 없다고 나오는 경우도 있는데, 그 때는

// ubuntu 의 경우

$ sudo apt-get install git-email

하면된다.

이렇게 해서 적절한 CC로 메일이 일단 전달되면 몇일 내로 개발자에게 답변이 온다고 한다. 답변은 accept 해주거나 comment 를 포함해서 온다고 한다. (comment 가 날아오면 그것을 해결하고 다시 보내면 될 듯.)

이상 여기까지 초보 개발자가 kernel 에 contribution을 하는 방법을 알리는 blog 를 나름 번역을 해봤다.

원문 : http://lotphelp.com/lotp/beginner-guide-linux-kernel-hacking