Documentudy

Red-Black Tree in Linux Kernel - Part 2

Mon, 15 Nov 2021 13:00:00 +0000

작성: 숲사람

지난 포스트에서 Red Black Tree의 일반적인 동작 방식을 이해~~하려고 시도~~해 보았다. 이번 포스트에서는 Linux Kernel에서 RB Tree가 어떻게 구현되었는지 살펴볼 것이다. 최신 리눅스 커널 버전은 v5.15 이지만, 이 문서를 쓰던 당시 커널버전은 v4.6 이었기 때문에 소스코드 분석은 v4.6버전 기준으로 하였다. 참고한 소스코드는 문서 하단 References 참고.

Kernel source에는 lib/rbtree_test.c 파일이 있다. Kernel에서 RB tree를 어떻게 사용하는지 친절하게 예를 들어주는 파일이다. 이를 통해 RB tree 사용법, 그리고 lib/rbtree.c 파일을 분석함으로써, Kernel에서 RB tree의 Insert / Erase 동작은 어떻게 구현되었는지 파악 해볼 것이다.

아래 소스코드를 보면 | + "" 등이 함께 표현되어있는데, 이는 중요도가 낮은 코드는 제거, 불필요한 공백과 indent 를 처리하고, 다른 파일에 위치한 코드를 쉽게 따라가기 위해 내가 만든 코드 분석 방법이다(추후 설명페이지 공유예정).

사용법 및 구조체 분석
삽입과 삭제 연산에서 자주 사용하는 내부API 정리
삽입 연산
- __rb_insert() 분석
삭제 연산
- __rb_erase_augmented() 분석
- ____rb_erase_color() 분석
References

사용법 및 구조체 분석

Linux Kernel RB Tree API 사용법 요약

자세한 내용은 lib/rbtree_test.c 파일 참고

구조체에 struct rb_node * 멤버 추가
전역 rb_root 구조체 변수 생성
my_insert 함수 작성
my_erase 함수 작성

`rb_node` 구조체

struct rb_node {  
	unsigned long  __rb_parent_color; /* rb parent and color */  
	struct rb_node *rb_right;  
	struct rb_node *rb_left;  
} __attribute__((aligned(sizeof(long))));  

실제 rb tree규칙으로 트리의 균형이 맞는지 rebalence 되는 노드의 구조체.
__attribute__((aligned(sizeof(long)))); 의미는?
구조체의 시작 주소 정렬
구조체의 시작주소가 4또는8의 배수(long크기)가 됨.
long형은 32bit 일때는 4byte, 64bit 일때는 8byte
참고: http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Type-Attributes.html#Type-Attributes
__rb_parent_color에는 부모노드의 주소값이 long으로 형변환되어 저장된다.
주소는 4 혹은 8의 배수로 증가하기 때문에 하위 2~3비트는 사용되지 않는다.
rb_node에서는 이 사용하지 않는 비트를 색 지정으로 사용하여 추가 변수 필요없이 메모리 공간을 절약한다.
그래서 rb_parent_color 멤버 변수를 통해 부모노드 주소__와 __본인노드 색 두가지를 동시에 가질 수 있다.
__rb_parent_color 변수의 더 정확한 의미는 rb parent and color이다.
과거 Linux Kernel 2.4.31의 rb_node 구조체 과거에는 rb_parent와 rb_color가 독립적인 변수로 존재하는것을 알 수 있다. 메모리 공간이 더 낭비 되었을 것이다.

typedef struct rb_node_s
{
        struct rb_node_s * rb_parent;
        int rb_color;
#define RB_RED          0
#define RB_BLACK        1
        struct rb_node_s * rb_right;
        struct rb_node_s * rb_left;
}
rb_node_t;

소스코드 확인: https://elixir.bootlin.com/linux/2.4.31/source/include/linux/rbtree.h#L100

rbtree가 적용된 노드 구조체

"lib/rbtree_test.c"  
struct test_node {  
	u32 key;  
	struct rb_node rb;  
	u32 val;
	u32 augmented;
}  

User가 실제 사용하는 구조체를(여기서는 struct test_node) rbtree로 구성하고 싶으면, 해당 구조체에 struct rb_node rb; 멤버를 추가하면 된다.
따라서 rbtree API에서는 rb멤버 포인터의 상위 구조체 포인터를(rb tree로 구성된 사용자 구조체가됨) 얻기위해 항상 rb_entry()를 사용하는데 이게 중요하다(container_of() 랑 동일한 역할을 하는 매크로 함수이다)

root 노드 생성

rbtree를 사용하려면 아래 처럼 전역으로 rb tree의 root 초기화 해야한다.

lib/rbtree_test.c

"lib/rbtree_test.c"  
static struct rb_root root = RB_ROOT;  

include/linux/rbtree.h

"include/linux/rbtree.h"  

#define RB_ROOT	(struct rb_root) { NULL, }

struct rb_root {
	struct rb_node *rb_node;
};

삽입과 삭제 연산에서 자주 사용하는 내부API 정리

주요 define

#define	RB_RED		0
#define	RB_BLACK	1

#define __rb_color(pc)     ((pc) & 1) 		"마지막 색지정 비트만 추출"
#define __rb_is_black(pc)  __rb_color(pc) 	"마지막 비트가 1이면 black"
#define __rb_is_red(pc)    (!__rb_color(pc)) 	"마지막 비트가 0이면 red"

#define rb_color(rb)       __rb_color((rb)->__rb_parent_color)
#define rb_is_red(rb)      __rb_is_red((rb)->__rb_parent_color)
#define rb_is_black(rb)    __rb_is_black((rb)->__rb_parent_color)

#define rb_parent(r)   ((struct rb_node *)((r)->__rb_parent_color & ~3))
#define __rb_parent(pc)    ((struct rb_node *)(pc & ~3))
"마지막 두비트를 0으로 만듦으로써 순수한 주소값으로 만듦"

`rb_entry()`

container_of와 같음. 구조체 멤버 포인터를 알때 그 구조체 포인터를 얻는 매크로 rb_node 포인터를 가지고있는 my_rb_struct같은 사용자 구조체의 포인터를 얻을 수 있음.

#define	rb_entry(ptr, type, member) container_of(ptr, type, member)

`rb_red_parent(red)`

전달받은 노드의 부모노드 주소(pointer) 리턴
__rb_parent_color 가 (struct rb_node *) 로 형변환 됨에 주의

+ static inline struct rb_node *rb_red_parent(struct rb_node *red)
| return (struct rb_node *)red->__rb_parent_color;

`rb_set_parent_color(rb, p, color)`

첫번째 파라미터 rb의 부모주소변수에 p저장, 동시에 rb의 color도 지정
두가지 일을 한번에함

+ static inline void rb_set_parent_color(struct rb_node *rb,  
				       struct rb_node *p, int color)  
| rb->__rb_parent_color = (unsigned long)p | color;  

`rb_set_parent(rb, p)`

위 rb_set_parent_color 와 동일한데 따로 color지정 필요없이 색지정은 p의 색으로.
rb의 부모주소 변수에 p 저장, 동시에 색은 p의 색으로 지정

+ static inline void rb_set_parent(struct rb_node *rb, struct rb_node *p)  
| rb->__rb_parent_color = rb_color(rb) | (unsigned long)p;  

`__rb_rotate_set_parents(old, new, ..., color)`

old 노드(O)를 기준으로 new 노드(N)를 올리는 회전연산이 일어날때 부모 변경시 사용.
old 자리가 new로 대체 될때 사용. 부모주소 변경.
new의 rb_parent_color에 old의 부모 주소를 저장,
동시에 old색 color로 변경

       P               P  
      /               /  
    (O)             (N)  
    / \             / \  
   l  (N)   -->   (O)  r  
      / \         / \  
     m   r       l   m  

+ __rb_rotate_set_parents(struct rb_node *old, struct rb_node *new,  
| 		struct rb_root *root, int color)  
| struct rb_node *parent = rb_parent(old); "O의 부모노드 P 얻음"  
| new->__rb_parent_color = old->__rb_parent_color; "N의 부모로 old의 부모노드 P 지정"  
| rb_set_parent_color(old, new, color); "O의 부모로 N 지정"  
| __rb_change_child(old, new, parent, root); "P의 자식에 new연결"  

`__rb_change_child(old, new, parent, ...)`

parent의 자식노드에 new연결 (기존에 old가 parent의 어느쪽 자식이었는지에 따라서)

+ __rb_change_child(struct rb_node *old, struct rb_node *new,  
		  struct rb_node *parent, struct rb_root *root)  
| if (parent)  
| | if (parent->rb_left == old)  
| | | parent->rb_left = new;  
| | else  
| | | parent->rb_right = new;  
| else  
| | root->rb_node = new;  

삽입 연산

먼저 어떤 기준으로 rbtree 를 정렬할지는 user가 직접 작성해야할 몫이다. 그래서 아래 insert()함수는 rbtree api를 사용하여 user가 직접 구현한 함수이다.

"lib/rbtree_test.c"  
+ static void insert(struct test_node *node, struct rb_root *root)  
| " *node : 새로 삽입할 노드, *root 현재 트리의 root 전역변수임 "  
| struct rb_node **new = &root->rb_node, *parent = NULL;  
| " **new는 처음에 root->rb_node의 포인터를 가지고 있음"  
| u32 key = node->key;  
| while ( *new)  
| | parent = *new;  
| | if (key < rb_entry(parent, struct test_node, rb)->key)  
| | " rb_entry로 얻은 현재 부모노드의 key랑 삽입노드의 key비교 "  
| | | new = &parent->rb_left;  
| | | "new는 결국 새node를 삽입할 위치를 가리키는 포인터의 포인터가 됨"  
| | else  
| | | new = &parent->rb_right;  
| rb_link_node(&node->rb, parent, new);  
| "new의 위치에 삽입할 node를 연결함"   
|---   
| "include/linux/rbtree.h"   
| + static inline void rb_link_node(struct rb_node * node, struct rb_node * parent,  
				struct rb_node ** rb_link)  
| | node->__rb_parent_color = (unsigned long)parent;  
| | "parent node의 주소를 저장함, 이 변수는 나중에 color를 지정하는 역할도 함"  
| | node->rb_left = node->rb_right = NULL;  
| | "새 node의 자식은 NULL"  
| | *rb_link = node;  
| | "삽입할 위치 rb_link에 새node 연결"  
|---   
| rb_insert_color(&node->rb, root);  
| "rb tree balancing 동작 수행"  
|---   
| + void rb_insert_color(struct rb_node *node, struct rb_root *root)  
| | __rb_insert(node, root, dummy_rotate);  

여기까지가 user가 구현해야할 함수 이고 내부에 __rb_insert() 함수가 실제 RB Tree의 Balancing이 일어나는 함수이다.

`__rb_insert()` 분석

RB tree에서 삽입하는 동작은 아래와 같이 세가지 형태 변화가 있다. 이전 포스트의 case 3/4/5와 동일한 동작. 아래 그림에서 소문자 노드는 빨간색, 대문자 노드는 검정색을 표현했다.
FIXME 참고로 실제 소스코드에서 case가 1,2,3으로 되어있으나, 여기서 case가 3,4,5 로 표기한 이유는, 이해의 편의를 위해 지난 포스트에서 정의한 case와 동일하게 맞추기 위함이다.

Case 3 - color flips  
  
      G            g  
     / \          / \  
    p   u  -->   P   U  
   /            /  
  n            n  
  
Case 4 - left rotate at parent  
  
     G             G  
    / \           / \  
   p   U  -->    n   U  
    \           /  
     n         p  
  
Case 5 - right rotate at gparent  
  
       G           P  
      / \         / \  
     p   U  -->  n   g  
    /                 \  
   n                   U  

이제 __rb_insert() 소스코드를 분석해보자.

+ __rb_insert(struct rb_node *node, struct rb_root *root,  
| " *node : 삽입된 노드, *root 루트노드"  
| struct rb_node *parent = rb_red_parent(node), *gparent, *tmp;  
| "삽입된 노드를 이용해 루트노드 얻어옴 : parent 주소 리턴하는 함수"   
| while (true)   
| | if (!parent) "parent가 없는 root노드인경우"  
| | | rb_set_parent_color(node, NULL, RB_BLACK); "node를(root) black으로 하고 종료"  
| | | break;   
| | else if (rb_is_black(parent)) " parent가 black인 경우 문제없으므로 종료"  
| | | break;  
| | gparent = rb_red_parent(parent); " 할아버지 노드"  
| | tmp = gparent->rb_right; " 삼촌노드"  
  
| | if (parent != tmp) 	" parent == gparent->rb_left 이고"  
| | | if (tmp && rb_is_red(tmp)) "tmp는 삼촌노드가 됨, 삼촌이 빨강이면"  
| | | | " Case 3 - color flips "  
| | | |   
| | | | 	     G            g  
| | | | 	    / \          / \  
| | | | 	   p   u  -->   P   U  
| | | | 	  /            /  
| | | | 	 n            n  
| | | |   
| | | | rb_set_parent_color(tmp, gparent, RB_BLACK); "삼촌 블랙"  
| | | | rb_set_parent_color(parent, gparent, RB_BLACK); "부모 블랙으로"  
| | | | node = gparent;"현재노드 gparent로 변경"  
| | | | parent = rb_parent(node);  
| | | | rb_set_parent_color(node, parent, RB_RED); "할아버지노드 빨간색"  
| | | | continue; "현재노드는 gparent로 재귀적으로 다시 수행 while 다시반복"  
  
| | | tmp = parent->rb_right;   
| | | if (node == tmp) "현재 노드가 부모의 오른쪽 자식 이면"  
| | | | " Case 4 - left rotate at parent : left 회전 부모색 빨강"  
| | | |   
| | | | 	    G             G  
| | | | 	   / \           / \  
| | | | 	  p   U  -->    n   U  
| | | | 	   \           /  
| | | | 	    n         p  
| | | |   
| | | | parent->rb_right = tmp = node->rb_left;  
| | | | node->rb_left = parent; "parent는 현재노드의 좌측 자식으로 "  
| | | | if (tmp)  
| | | | | rb_set_parent_color(tmp, parent, RB_BLACK);  
| | | | rb_set_parent_color(parent, node, RB_RED); "parent의 부모노드주소에 node가 저장됨"  
| | | | augment_rotate(parent, node); "현재 이 함수는 dummy_rotate()이므로 무시"  
| | | | parent = node; "현재노드가 부모노드가 됨, 어차피 gparent->left는 parent였으니 이부분은 수정 필요 없음"  
| | | | "그렇다면 현재노드위치는 어디? -> 이 이후부터 p의 left(현재노드)는  
고려할 필요가 없음. 그래서 따로 현재노드를 지정해줄 필요없이 앞으로는 g와 p의 관계만만 고려하면 됨 "  
| | | | tmp = node->rb_right;  
| | | " Case 5 - right rotate at gparent "  
| | | " case 5 동작 으로 마무리"  
| | |  
| | |	      G           P  
| | |	     / \         / \  
| | |	    p   U  -->  n   g  
| | |	   /                 \  
| | |	  n                   U  
| | |  
| | | gparent->rb_left = tmp;  /* == parent->rb_right */  
| | | parent->rb_right = gparent;  
| | | if (tmp)  
| | | | rb_set_parent_color(tmp, gparent, RB_BLACK);  
| | | __rb_rotate_set_parents(gparent, parent, root, RB_RED);  
| | | "parent색을 gparent의 부모색으로 변경(==부모주소변경), gprent는 빨강으로 변경"  
| | |---   
| | | + __rb_rotate_set_parents(struct rb_node *old, struct rb_node *new,  
| | | | 		struct rb_root *root, int color)  
| | | | "old : gparent, new : parent"  
| | | | struct rb_node *parent = rb_parent(old);  
| | | | new->__rb_parent_color = old->__rb_parent_color; "parent의 부모주소 값을 gparent의 부모주소로 변경"  
| | | | rb_set_parent_color(old, new, color); "gparent의 부모주소 값을 parent 로"  
| | | | __rb_change_child(old, new, parent, root);  
| | | | " (gparent의 부모밑에 parent연결)"  
| | | |---   
| | | | "parent 자식으로 new를 연결 하는 함수"  
| | | | + __rb_change_child(struct rb_node *old, struct rb_node *new,  
| | | | | 		  struct rb_node *parent, struct rb_root *root)  
| | | | | if (parent)  
| | | | | | if (parent->rb_left == old)  
| | | | | | | parent->rb_left = new;  
| | | | | | else  
| | | | | | | parent->rb_right = new;  
| | | | | else  
| | | | | | root->rb_node = new;  
| | | |---   
| | |---   
| | | augment_rotate(gparent, parent); "dummy"
| | | break;  

| | else " 여기부터는 parent == gparent->rb_right 인 반대의 경우이고"  
| | "아래 코드는 case 3,4,5 로 위에서 분석한 내용과 방향만 반대일뿐 동일함"  
| | | tmp = gparent->rb_left;  
| | | if (tmp && rb_is_red(tmp))  
| | | | " Case 3 - color flips "  
| | | | ...  
| | | tmp = parent->rb_left;  
| | | if (node == tmp)  
| | | | " Case 4 - right rotate at parent "  
| | | | ...  
| | | " Case 5 - left rotate at gparent "  
| | | ...  
  

삭제 연산

삭제 연산도 마찬가지로 유져가 직접 rb_erase() api를 이용해 함수를 작성한다. 여기까지가 user가 구현해야할 함수 이다.

"lib/rbtree_test.c"  
+ static inline void erase(struct test_node *node, struct rb_root *root)  
| " *node : tree에서 삭제할 노드"  
| rb_erase(&node->rb, root);  

이제 rb_erase() 소스코드를 분석해보자. 대략적인 개요는 다음과 같다.

"lib/rbtree.c"  
void rb_erase(struct rb_node *node, struct rb_root *root)  
| struct rb_node *rebalance;  
| rebalance = __rb_erase_augmented(node, root, &dummy_callbacks);  
| "1. 노드 삭제시키고 tree가 rebalence대상이 되는지 판단"  
| if (rebalance)  
| | ____rb_erase_color(rebalance, root, dummy_rotate);  
| | "2. 삭제 연산의 rebalence 동작 수행"  

`__rb_erase_augmented()` 분석

노드를 삭제하고 그자리에 successor(후계노드)를 찾아서 대체 시키는 함수이다. 그뒤 트리의 균형이 맞는지 rebalence가 필요한지 판단해서 리턴값으로 알려준다. 참고로 Linux Kernel에서는 leftmost successor(오른쪽 sub트리중 가장 작은 노드)를 후계노드로 선정한다. 그래서 코드는 오른쪽 한방향일 경우만 고려해서 작성되어 있다.

__rb_erase_augmented() 개요

+ __rb_erase_augmented(struct rb_node *node, struct rb_root *root,  
		     const struct rb_augment_callbacks *augment)  
| struct rb_node *child = node->rb_right, *tmp = node->rb_left;  
| struct rb_node *parent, *rebalance;
| unsigned long pc;
| "case 1"  
| if (!tmp) "오른쪽 자식만 있거나 아얘없는 경우"  
| |
| |     (n)          (s)
| |       \     ->     
| |       (s)  
| |
| | "오른쪽 자식을 대체시키고 끝"  
| | if (child) "삭제노드에 오른쪽 자식만 있는경우"  
| | | "대체된 child의 색을 삭제되는 노드색으로 (동시에 부모노드의 주소도 됨"  
| | else "삭제될 노드에 자식이 없는 경우"  
| | | "삭제될 노드 색이 black이면 5)black height규칙에 위반되기 때문에 rebalence 대상임"  
| else if (!child) "왼쪽 자식만 있는 경우"  
| | "위와 똑같이 삭제노드를 왼쪽자식으로 대체시키고 끝"  
| else "양쪽 자식이 존재하는 경우"  
| | if (!tmp) "case 2 :삭제노드의 오른자식(successor)에 왼쪽자식이 없는경우"  
| | | "이경우는 삭제노드의 오른쪽자식이 바로 후계노드가 되기 때문에 간단"  
| | |     (n)          (s)
| | |     / \          / \
| | |   (x) (s)  ->  (x) (c)
| | |         \
| | |         (c)
| | else "case 3 : 삭제노드의 오른자식에 왼쪽 sub 트리가 존재하는 경우"  
| | |
| | |    (n)          (s)
| | |    / \          / \
| | |  (x) (y)  ->  (x) (y)
| | |      /            /
| | |    (p)          (p)
| | |    /            /
| | |  (s)          (c)
| | |    \
| | |    (c)
| |   
| | "삭제노드의 왼쪽 자식은 successor의 왼쪽자식이됨"  
| | "삭제노드의 부모노드의 자식으로 successor연결"  
| | if (child2) " successor의 우측 자식(child2)이 있었다면 "
| | | "child2는 블랙으로"  
| | | "s, c둘중 적어도 하나는 무조건 블랙이었기 때문"  
| | else  
| | | "삭제 노드의 부모 노드 저장, 동시에 색은 삭제노드와 동일하게"  
| | | "successor의 기존 부모의 색이 블랙 이었다면? rebalence대상임"  
| |   
| return rebalance;  

__rb_erase_augmented() 분석

"include/linux/rbtree_augmented.h"  
+ __rb_erase_augmented(struct rb_node *node, struct rb_root *root,  
		     const struct rb_augment_callbacks *augment)  
| struct rb_node *child = node->rb_right, *tmp = node->rb_left;  
| struct rb_node *parent, *rebalance;
| unsigned long pc;
| "case 1"  
| if (!tmp) "오른쪽 자식만 있거나 아얘없는 경우"  
| | "오른쪽 자식을 대체시키고 끝"  
| | pc = node->__rb_parent_color; "삭제할 노드의 색" 
| | parent = __rb_parent(pc); "삭제할 노드의 부모노드"  
| | __rb_change_child(node, child, parent, root); "parent의 자식에 child연결"  
| |   
| | if (child) "삭제노드에 오른쪽 자식만 있는경우"  
| | | child->__rb_parent_color = pc; "대체된 child의 색을 삭제되는 노드색으로 (동시에 부모노드의 주소도 됨"  
| | | rebalance = NULL; "rebalance필요없음"  
| | else "삭제될 노드에 자식이 없는 경우"  
| | | rebalance = __rb_is_black(pc) ? parent : NULL;  
| | | "삭제될 노드 색이 black이면 5)black height규칙에 위반되기 때문에 rebalence 대상임"  
| else if (!child) "왼쪽 자식만 있는 경우"  
| | "위와 똑같이 삭제노드를 왼쪽자식으로 대체시키고 끝"  
| else "양쪽 자식이 존재하는 경우"  
| | "kernel rbtree 에서는 leftmost successor(오른쪽 sub트리중 가장 작은 노드)를 후계노드로 대체함"  
| | struct rb_node *successor = child, *child2;  
| | tmp = child->rb_left;  
| | if (!tmp) "case 2 :삭제노드의 오른자식(successor)에 왼쪽자식이 없는경우"  
| | | "이경우는 삭제노드의 오른쪽자식이 바로 후계노드가 되기 때문에 간단"  
| | |
| | |     (n)          (s)
| | |     / \          / \
| | |   (x) (s)  ->  (x) (c)
| | |         \
| | |         (c)
| | |
| | | parent = successor; "parent는 successor를 의미"  
| | | child2 = successor->rb_right;  
| | else "case 3 : 삭제노드의 오른자식에 왼쪽 sub 트리가 존재하는 경우"  
| | |
| | |    (n)          (s)
| | |    / \          / \
| | |  (x) (y)  ->  (x) (y)
| | |      /            /
| | |    (p)          (p)
| | |    /            /
| | |  (s)          (c)
| | |    \
| | |    (c)
| | |
| | | do   
| | | | parent = successor; "y" 
| | | | successor = tmp;  
| | | | tmp = tmp->rb_left;  
| | | while (tmp); "오른자식 y 왼쪽 sub트리에서 가장 왼쪽(작은) 노드(tmp) 찾기 "  
| | | parent->rb_left = child2 = successor->rb_right;  
| | | successor->rb_right = child;  
| | | rb_set_parent(child, successor);   
| | | "삭제노드자리에 successor위치 시킴, 그에따른 자식노드 처리"  
| |   
| | "case 2,3 모두해당"  
| | successor->rb_left = tmp = node->rb_left;  
| | rb_set_parent(tmp, successor);  
| | "삭제노드의 왼쪽 자식은 successor의 왼쪽자식이됨"  
| | pc = node->__rb_parent_color;  
| | tmp = __rb_parent(pc);  
| | __rb_change_child(node, successor, tmp, root);  
| | "삭제노드의 부모노드의 자식으로 successor연결"  
| | if (child2) " successor의 우측 자식(child2)이 있었다면 "
| | | successor->__rb_parent_color = pc;  
| | | rb_set_parent_color(child2, parent, RB_BLACK);  
| | | rebalance = NULL;  
| | | "child2는 블랙으로"  
| | | " s, c둘중 적어도 하나는 무조건 블랙이었기 때문"  
| | else  
| | | unsigned long pc2 = successor->__rb_parent_color;  
| | | successor->__rb_parent_color = pc; "삭제 노드의 부모 노드 저장, 동시에 색은 삭제노드와 동일하게"  
| | | rebalance = __rb_is_black(pc2) ? parent : NULL;  
| | | "successor의 기존 부모의 색이 블랙 이었다면? rebalence대상임"  
| |   
| return rebalance;  
| "만약 rebalance가 NULL이 아니라면 return되는 rebalance는 "  
| "case 1 : n(삭제할노드)의 부모 "  
| "case 2 : successor임 (successor자체가 successor원래 부모위치로 올라가기때문)"  
| "case 3 : 대체되기 전 successor의 원래 부모 "  
|   
| "결국 삭제되는 위치(후계노드-successor이든, 실제 자식없는 삭제노드이든)의 부모노드임"  
| "successor가 없다면 (case1) -> 삭제노드의 부모노드"  
| "successor가 있다면 (case 2,3) -> 대체되기전 successor의 부모위치와 같음"  
  

`____rb_erase_color()` 분석

__rb_erase_augmented() 이후
이미 삭제할 노드는 트리에서 제거 되었고 후계자노드(successor)로 대체된 상태부터 시작된다. 매개변수로 넘어온 parent는 삭제된(대체노드) 노드의 원래 부모노드임을 주의.

____rb_erase_color() 개요

+ ____rb_erase_color(struct rb_node *parent, struct rb_root *root,  
	void ( *augment_rotate)(struct rb_node *old, struct rb_node *new))  
| struct rb_node *node = NULL, *sibling, *tmp1, *tmp2;  
| while (true)  
| | sibling = parent->rb_right;  
| | if (node != sibling) 	/* node == parent->rb_left */  
| | | if (rb_is_red(sibling))   
| | | | " delete_case 2 : 형제가 레드인 경우"  
| | | if (!tmp1 || rb_is_black(tmp1))   
| | | | if (!tmp2 || rb_is_black(tmp2))   
| | | | | if (rb_is_red(parent))  
| | | | | | "delete_case 4 : 형제자식 모두 블랙, 부모 레드"  
| | | | | else  
| | | | | | "delete_case 3: 형제자식 모두 블랙, 부모 블랙"  
| | | | "delete_case 5 : 무조건 형제가 검은색인경우가 됨"  
| | | | ...  
| | | "delete_case6"  
| | else	/* node == parent->rb_right */  
| | | "위와 동일한 케이스 방향만 반대"  
  

참고로 위의 case번호는 rbtree_general.md 파일에서 규정한 번호임, 실제코드랑은 다름

____rb_erase_color() 분석

+ ____rb_erase_color(struct rb_node *parent, struct rb_root *root,  
	void ( *augment_rotate)(struct rb_node *old, struct rb_node *new))  
| struct rb_node *node = NULL, *sibling, *tmp1, *tmp2;  
| while (true)  
| | sibling = parent->rb_right;  
| | if (node != sibling) 	" node == parent->rb_left "  
| | | if (rb_is_red(sibling))   
| | | | " delete_case 2 : 형제가 레드인 경우"  
| | | | " Case 1 - Left rotate at parent"  
| | | |  
| | | | 	     P               S  
| | | | 	    / \             / \  
| | | | 	   N   s    -->    p   Sr  
| | | | 	      / \         / \  
| | | | 	     Sl  Sr      N   Sl  
| | | |  
| | | | parent->rb_right = tmp1 = sibling->rb_left;  
| | | | sibling->rb_left = parent;  
| | | | rb_set_parent_color(tmp1, parent, RB_BLACK); "형제를 블랙으로"  
| | | | __rb_rotate_set_parents(parent, sibling, root, RB_RED); "회전연산"  
| | | | sibling = tmp1; "형제를 Sl 로 변경, Sl은 무조건 블랙 이 이후 형제는 무조건 블랙"  
  
| | | tmp1 = sibling->rb_right;  
| | | if (!tmp1 || rb_is_black(tmpl1)) "형제 우측자식 블랙 이고"  
| | | | tmp2 = sibling->rb_left;  
| | | | if (!tmp2 || rb_is_black(tmp2))  "형제 좌측자식 블랙"  
| | | | | " Case 2 - Sibling color flip  
| | | | |   (p could be either color here)"  
| | | | |  
| | | | | 	     (p)           (p)  
| | | | | 	     / \           / \  
| | | | | 	    N   S    -->  N   s  
| | | | | 	       / \           / \  
| | | | | 	      Sl  Sr        Sl  Sr  
| | | | |  
| | | | | rb_set_parent_color(sibling, parent, RB_RED); "형제를 레드로"  
| | | | | if (rb_is_red(parent))  
| | | | | | "delete_case 4 : 형제자식 모두 블랙, 부모 레드 경우"  
| | | | | | rb_set_black(parent); "부모를 블랙으로"  
| | | | | else  
| | | | | | "delete_case 3: 형제자식 모두 블랙, 부모 블랙 경우"  
| | | | | | node = parent;  
| | | | | | parent = rb_parent(node);  
| | | | | | if (parent)  
| | | | | | | continue; "부모노드 기준으로 다시 처음부터"  
| | | | | break; "종료"  
  
| | | | " delete_case 5 : 무조건 형제가 검은색인경우가 됨"  
| | | | " Case 3 - Right rotate at sibling  
| | | |   (p could be either color here)"  
| | | | 	  
| | | | 	   (p)           (p)  
| | | | 	   / \           / \  
| | | | 	  N   S    -->  N   Sl  
| | | | 	     / \             \  
| | | | 	    sl  Sr            s  
| | | | 	      \              / \  
| | | | 	      tmp1        tmp1  Sr  
| | | |  
| | | | sibling->rb_left = tmp1 = tmp2->rb_right; "tmp2: sl"  
| | | | tmp2->rb_right = sibling;  
| | | | parent->rb_right = tmp2; "s 기준 right 회전연산"  
| | | | if (tmp1)  
| | | | | rb_set_parent_color(tmp1, sibling, RB_BLACK); "tmp1의 부모를 s 로"  
| | | | tmp1 = sibling;  
| | | | sibling = tmp2;  
  
| | | "delete_case6"  
| | | " Case 4 - Left rotate at parent + color flips  
| | |   (p and sl could be either color here. After rotation, p becomes black, s acquires  
| | |   p`s color, and sl keeps its color) "  
| | |   
| | | 	       (p)             (s)  
| | | 	       / \             / \  
| | | 	      N   S     -->   P   Sr  
| | | 	         / \         / \  
| | | 	       (sl) sr      N  (sl)  
| | |   
| | | parent->rb_right = tmp2 = sibling->rb_left; "tmp2: sl"  
| | | sibling->rb_left = parent;  
| | | rb_set_parent_color(tmp1, sibling, RB_BLACK); "tmp1 : sr"  
| | | "p 기준 left회전"  
| | | if (tmp2)  
| | | | rb_set_parent(tmp2, parent); "sl은 p색으로"  
| | | __rb_rotate_set_parents(parent, sibling, root, RB_BLACK); "p 기준 left회전, p색 블랙으로"  
| | | break; "종료"  
  
| | else	" node == parent->rb_right "  
| | | "여기부터는 위와 동일한 케이스 방향만 반대"  
  

References

Red-Black Tree in Linux Kernel - Part 1

Sun, 14 Nov 2021 13:00:00 +0000

작성: 숲사람

Red-Black Tree 란?
RB tree의 5가지 규칙
삽입 연산
삭제 연산
- 삭제되는 노드 처리
- 후계자 노드 처리
References

Red-Black Tree 란?

RB-Tree 는 Radix-Tree와 더불어 Linux Kernel에서 가장 많이 사용하는 Tree 자료구조이다. I/O scheduler(CFQ, deadline 등), ext filesystem, Virtual memory areas 등 Kernel의 여러 Subsystem에서 사용된다. 기존 Tree자료구조의 단점은 최악의 경우 노드가 Linked-List의 형태로 저장되어 탐색 시간복잡도가 O(N) 이 된다는 점이다. 하지만 RB Tree는 노드의 삽입과 삭제가 이루어 질때, Tree가 자동으로 회전하며 O(logN)의 시간복잡도를 보장한다.

이 글에서는 일반적인 RB Tree에서 가장 복잡한 연산인 삽입과 삭제가 어떤 방식으로 동작 하는지 알아본다. 경우의 수만 잘 따지고 그때그때 어떻게 해주는지 규칙만 잘 파악하면 쉽게 따라갈 수 있다. 이를 기반으로 해서 다음 글에서 Linux Kernel 에서 RB Tree가 어떻게 구현되었는지 살펴 볼것이다.

RB tree의 5가지 규칙

노드의 삽입과 삭제연산을 할때마다, 아래의 규칙을 만족시키도록 트리의 노드위치를 변경하거나 유지하는것이 RB Tree이다.

노드는 빨간색 검은색 둘 중 하나다(A node is either red or black)
Root 노드는 검은색이다. (The root is black)
모든 말단 노드는 검은색이다 (All leaves (NULL) are black)
빨간색 노드는 중첩될 수 없다. (Both children of every red node are black)
각 말단노드의 Black Height는 모두 동일하다 (Every simple path from root to leaves contains the same number of black nodes)

Black Height: 말단노드에서부터 Root노드 사이의 검은색 노드 갯수

삽입 연산

새노드가 트리에 삽입될때, 부모노드는 검은색인경우 빨간색인 경우 두가지가 있다. 아래 설명된 각각의 경우의 수에따라 5가지 종류의 삽입연산이 필요하다.

새노드 삽입 insert_case1() 수행  
  
-검은색에 삽입 -> 문제가 되지 않음   
-빨간색에 삽입   
	(1) 삼촌도 빨간색인 경우 insert_case3(n)  
		부모,삼촌 검은 색, 할아버지 빨간색으로   
	(2) 삼촌이 검은색인 경우 (여기서 삼촌은 할아버지의 오른쪽 자식으로 가정)  
    		1) 삽입노드가 부모노드의 오른쪽 자식인 경우 insert_case4(n)  
			삽입노드와 부모노드를 회전시켜 부모노드를 삽입노드의   
			왼쪽 자식으로 만든다.  -->  2)과 구조가 됨  
    		2) 삽입노드가 부모노드의 왼쪽 자식인 경우 insert_case5(n)   
			부모노드를 검은색 할아버지 노드를 빨간색으로 바꾸고  
			오른쪽회전 (부모노드가 루트위치로)  

일부 삽입연산은 트리의 회전연산이 필요하다(rotation_left() 및 rotation_right()). 회전연산은 매개변수로 전달된 노드의 자식을 치켜세워주는 연산이라고 생각하면 이해하기 쉽다 : 자식이 위로 부모는 아래로. 아래 그림은 부모노드(O)와 자식노드(N) 기준으로 rotation_left 회전이 일어날때 트리의 구조 변화이다.

       P               P  
      /               /  
    (O)             (N)  
    / \             / \  
   l  (N)   -->   (O)  r  
      / \         / \  
     m   r       l   m  

각각의 삽입 연산 동작 방식은 아래와 같다.

insert_case1(n)  
{  
	if (부모노드가 없는경우) -> n을 블랙 (루트노드가됨)  
	else (부모노드 있으면)  
		insert_case2(n) 수행  
}  

insert_case2(n)  
{  
	if ( 부모노드가 블랙인경우 ) 
		그냥 삽입해도 문제 안되므로 return  
	else(부모노드 빨강)  
		insert_case3(n) 수행		  
}  

insert_case3(n)  
{  
   	if( 삼촌노드 빨간색이면 && 삼촌노드 있으면)  
		부모,삼촌노드 검은색으로  
		할아버지노드 빨간색으로  
		insert_case1( 할아버지노드)   " 재귀적으로 수행 !!"  
	else  "그외 나머지 경우 (삼촌 노드가 검정색 || 삼촌노드 없으면)"  
		insert_case4 (n)  
}  

insert_case4()는 case5 함수를 수행할 구조로 만드는 작업이다.

insert_case4(n) 
{	  
	if (부모노드가 할아버지 노드의 왼쪽자식 && 새노드가 부모노드의 오른쪽자식 )  
		rotation_left(부모노드)	  
		n = n->왼쪽노드  
	if(부모가 할아버지의 오른쪽 자식 && 새노드가 부모 노드의 왼쪽 자식)					  
		rotation_right(부모노드);  
		n = n->오른쪽노드  
  
	둘다 아니거나 위내용을 수행했으면  
	insert_case5(n) 수행  
  
}  

insert_case5(n) 
{  
	부모는 검은색으로 할아버지는 빨간색으로   
	if ( 부모가 할아버지의 왼쪽자식 && n이 부모의 왼쪽자식 )  
		rotation_right( 할아버지 노드)  
	else (부모가 할아버지 오른쪽 자식 && n이 부모의 오른쪽 자식 )  
		rotation_left( 할아버지 노드)  
  
}  

삭제 연산

삭제 연산은 삽입 연산보다는 다소 복잡한데, 삭제되는 노드를 처리해야하고, 삭제된 자리를 새로운 후계자 노드로 변경해야하기 때문이다.

삭제되는 노드 처리

삭제되는 노드에 대체되는 노드를 복사한다. 색은 삭제되는 노드색을 유지하고, 노드만 바로 복사된다. 대체될 수 있는 후계자는 이진트리 삭제와 마찬가지로 left 하위트리 에서 가장 큰 노드인데(삭제 노드의 왼쪽sub트리는 Inorder Predecessor 오른쪽은 Inorder successor라고 표현함), 보통 맨 아래 노드이고 (leaf node가 1개와 Null leaf1개) 이거나 (Null leaf만 두개)인 경우밖에 없다. 중요한건 이 대체되는 후계 노드가 그 자리에서 삭제 된다는것인데, 이때 RB트리의 규칙이 무너지는 경우가 있기 때문에, 대체되는 노드를 기준으로 아래 2번의 알고리즘을 따르게 된다. 가령 아래 트리에서 노드 40이 삭제된다면 그자리를 대체할 수 있는 후계노드는 노드 30이 될것이다.

아래 설명에서 n은 대체될 노드의 자식이다. 일반 노드가 될 수 도 있고 Null leaf(검은색)가 될수도 있다. 즉, 트리에서 삭제되는 노드 기준으로 트리 balancing동작을 시키는 것이 아니라 후계자 노드 기준으로 balancing동작 수행한다.

후계자 노드 처리

후계 노드가 삭제되는 것으로 판단하면 된다. 후계 노드가 빨간색일 경우와 검은색일 경우에 따른 케이스로 구분하면 된다. 아래 형제,부모,조카는 대체될 후계 노드 기준으로 위치한 노드이다. 실제로는 대체될 후계노드의 자식노드기준으로 볼 수도 있는데. 그이유는 대체될 노드는 삭제노드 위치로 변경되고 대체될 노드의 자리에는 어차피 그 노드의 자식노드가 위치할 것이기 때문이다.

- 후계노드가 빨간색 -> 문제 없음    
- 후계노드가 검은색     
	- 형제가 빨간색인 경우 delete_case2(n)    
	- 형제가 검은색인 경우    
		(3) 부모노드 검은색, 형제의 양쪽 자식이 모두 검은색 :  delete_case3(n)    
			->형제노드만 빨간색으로    
		(4) 부모노드는 빨간색, 형제의 양쪽 자식이 모두 검은색 : delete_case4(n)    
			->형제:빨간색 부모:검정색    
		(5) 삭제노드와 가까운 조카노드가 빨간색일때 : delete_case5(n)    
			-> 형제와 조카노드 색교환, 형제기준 조카노드를 올리는 방향의 회전    
			(아래 case6 조건으로 변경됨)    
		(6) 삭제노드와 먼 조카노드가 빨간색 (가까운조카색 관계없음) : delete_case6(n)    
			형제는 부모노드 색으로, 부모는 검은색으로     
			멀리있는 조카노드 검은색으로    
			부모노드 기준 형제를 올리는 방향의 회전     

삭제되는 후계자 노드 위치 기준으로 delete_one_child() 부터 시작한다.

 "여기서 n은 실제 트리에서 제거될 후계 노드의 자리를 차지하게 될 노드임에 주의"    
delete_one_child(n)     
{    
	child = is_leaf() "n의 자식"     
    
	child(n의 자식)를 삭제될 n(후계노드)있던 자리로 변경    
	if( n == 블랙)    
		if ( child == 레드)    
			child 블랙으로 변경    
		else    
			delete_case1(child) 호출 
			"n의 자식으로 case 1 부터 start!"    
			"여기서 child의 위치는 후계노드의 원래 위치와 동일함"  
}    

 "여기서 n은 대체노드의 자식노드 child임에 주의"    
delete_case1(n)    
{    
	if (삭제노드의 부모가 NULL이 아니면)    
		delete_case2(n) 호출    
}    

 "형제를 검은색, 부모를 빨간색으로 바꾸고 left/right회전!"    
delete_case2(n)
{    
	if (형제 == 레드)     
		부모노드를 빨간색, 형제노드를 검은색 변경    
		if ( n == 부모의 왼쪽자식)    
			rotation_left(부모노드)    
		else    
			rotation_right(부모노드)	    
			    
	delete_case3(n) 호출    
}    
    

delete_case3(n)    
{    
	if (형제==블랙 && 부모==블랙 && 형제 좌/우 자식==블랙)    
		형제를 빨간색    
		deletion_case1(부모노드) 호출    
	else    
		deletion_case4(n) 호출    
}    

delete_case4(n)    
{    
	if (형제==블랙 && 부모==레드 && 형제 좌/우 자식==블랙)    
		형제를 빨간색    
		부모를 검정색으로     
	else    
		deletion_case5(n) 호출    
	    
}    

delete_case5(n)	//case6 를 수행할 구조로 만드는 작업    
{    
	if (형제 == 블랙)    
		if (n이 부모노드의 왼쪽자식 && 형제 오른쪽자식==검정 && 형제 왼쪽자식==빨강)    
			형제노드 빨간색으로    
		 	형제 왼쪽 자식 검은색으로     
			rotation_right(형제노드)	    
		else if (n이 부모노드의 오른쪽 자식 && 형제 왼쪽자식==검정 && 형제 오른쪽자식==빨강)    
			형제노드 빨간색으로    
		 	형제 오른쪽 자식 검은색으로     
			rotation_left(형제노드)    
    
	deletion_case6(n) 호출    
}    

delete_case6(n)    
{    
	형제색 = 부모의 색으로    
	부모색 = 검정색으로    
	if (n이 부모의 왼쪽 자식이면)    
		형제의 오른쪽자식 검정색 으로    
		rotation_left(부모노드)    
	else "n이 부모의 오른쪽 자식"    
		형제의 왼쪽자식 검정색 으로    
		rotation_right(부모노드)    
}    

References

If 없이 Shell Script 분기 처리하기

Sun, 10 Oct 2021 13:00:00 +0000

Exit Status란 무엇인가
IF없이 커맨드 분기 처리
대괄호[]의 정체
IF 없이 조건 분기 처리
If Statement의 작동원리
References

if [ condition ]; then
    cmd
fi

나는 쉘스크립트를 처음 배울때, 일반적으로 사용되는 이 If 구문이 다소 난해하게 느껴졌다. then 의 존재가 생소했고, []의 대괄호가 정확히 무엇을 의미하는지 그리고 세미콜론이 왜 붙는지 등. 이해하지 않고 그냥 외웠다. 그래서 한때는 ;를 then뒤에 붙여야하는지 앞에 붙여아하는지 햇갈려서 매번 구글 검색을 했다. 이것들의 정확한 의미는 무엇일까?

한편 쉘스크립트를 작성할때, If Statement를 사용하지 않고도 분기 처리하는게 가능하다. 꽤 많은 경우에 ifelse 대신 &&||를 사용한다면 훨씬 깔끔하고 명료한 분기문을 작성 할 수 있다. 이 글에서는 ifelse 대신 &&||를 사용하는 분기에 대해 알아보고, 쉘스크립트의 IF Statement의 구조에 대해 조금더 명확하게 이해해 볼 것이다.

Exit Status란 무엇인가

우선 exit statue(혹은 exit code)에 대해 이해할 필요가 있다. UNIX운영체제 표준인 POSIX 표준에서 프로그램은 성공적으로 수행했을때 exit status 0을 리턴한다. 실패했을때는 1이상의 값을 리턴한다. 그래서 프로그램이나 쉘스크립트를 작성할때 exit status를 리턴하는것을 빼먹지 않도록 유의해야한다. 다른 프로그램과 스크립트에서 해당 프로그램이 정상적으로 수행되었는지 정확히 확인을 하기 위해서이다.

참고로 bash에서 exit status를 만들기 위해서는 exit 과 return 유틸리티(명령어)를 이용한다. (둘다 아마도 shell built-in commnad일것이다.)

return <number> 해당 함수를 종료하고 exit status를 <number> 으로 만든다. 함수에서만 사용가능. 함수 종료이후 echo $? 로 <number> 값이 무엇이었는지 확인가능하다. $?에는 이전 명령의 exit code값이 저장되어있다.
exit <number> 전체 스크립트를 종료하고 exit status를 <number>으로 만든다. 스크립트 종료 이후, 마찬가지로 echo $? 로 <number> 값을 확인가능하다.

IF없이 커맨드 분기 처리

cmd1이 정상적인 exit status를 리턴한다고 가정하고, 이전 명령의 성공/실패 여부에따라 cmd2를 수행해보자. 먼저 if/else를 사용한다면 다음과 같이 길고 다소 복잡해진다.

cmd1
if [ $? -eq 0 ]; then
    cmd2
fi

하지만 &&와 ||를 사용하면, 이를 한줄로 처리할수 있다. 코드가 훨신 간결해진다.

cmd1 성공시에만 cmd2 실행

cmd1 && cmd2

cmd1 실패시에만 cmd2 실행

cmd1 || cmd2

만약 cmd1이 성공했을때 cmd2를 실행하고, 실패할때 cmd3를 실행하고자 한다면 아래와 같이 한줄로 처리 가능하다.

cmd1 && cmd2 || cmd3

명령어에 대한 exit status 처리는 가능하면 && ||를 사용하는게 코드를 훨씬 간결하게 만든다.

대괄호`[]`의 정체

[ 는 test 와 동일한 커맨드이다. 따라서 [ 도 하나의 shell 명령어이자 프로그램이다. 다만 [ 는 반드시 마지막에 인자 ] 를 전달해야한다는점이 다를 뿐이다. test는 전달된 인자를 평가(evaluate)하는 유틸리티이다. 이 명령의 결과는 exit status 인데 전달된 인자가 True 인경우는 0 이고 False인 경우는 1이된다. [ 와 test는 POSIX 표준이기 때문에 대부분의 쉘에서 지원한다.

참고로 [[ 는 bash shell 에서 사용하는 [의 개선된 버전이다. bash가 아닌 shell에서 정상적으로 동작한다는 보장은 없지만, ksh, bash, zsh, yash, busybox sh에서는 지원한다고 한다.

if [ "aa" == "aa" ]
then 
    echo 'yes'
fi

if test "aa" == "aa"
then 
    echo 'yes'
fi

따라서 위 두 구문은 동일한 동작을 한다.

IF 없이 조건 분기 처리

위에서 대괄호도 결국 test 커맨드임을 알게 되었다. 따라서 명시적인 If Statement없이도 분기처리가 가능하다. 기존의 If 조건에 따른 분기 대신에 &&를 사용하여 작성하면 다음과 같이 할 수 있다.

condition이 true일때만 cmd 수행

[ condition ] && cmd

condition이 false 일때만 cmd가 수행.

[ condition ] || cmd

condition에 따라 if/else 처리

[ condition ] && cmd1 || cmd2

condition이 true이면 cmd1 false이면 cmd2가 수행된다. 아래와 동일한 동작이다.

if [ condition ]
then
    cmd1
else
    cmd2
fi

한가지 주의할 점은 shell에서는 무조건 왼쪽에서 오른쪽으로 순차적으로 명령과 연산자를 수행한다는 점이다. c언어처엄 논리 연산자 우선순위에 따라 명령을 처리하지 않는다. 가령 [ condition ] && cmd1 && cmd2 || cmd3 은 먼저 [ condition ] 명령이 성공하면 cmd1명령을 실행하고 cmd1이 성공하면 cmd2가 실행된다. 그리고 만약 cmd1이 실패하면 cmd2는 실행되지 않고 cmd3이 실행된다.

#! /bin/bash

[ condition ] && cmd1
echo "hello"

또 주의할 사항이 있다. 만약 위와 같이 스크립트를 작성한경우 condition이 False이면 exit 1이 리턴된다. 그 뜻은 echo "hello" 라인이 수행되기도 전에 이 스크립트 자체가 비정상 종료된다는 뜻이다. 만약 If Statement를 사용했다면 “hello”는 출력되지 않았겠지만 전체스크립트가 비정상 종료되지는 않았을것이다. 따라서 if/else대신 && ||를 사용한다면 exit status에 대한 처리에 주의해야할 것이다.

그렇다면 위에서 condition이 False인경우 아무것도 하지 않고 다음 라인 echo "hello" 을 실행하기 위해서는 어떻게 하면 될까? 두가지 해결 방안이 있다.

먼저 set -e 처리를 하면 exit 1이 발생하지 않는다. 참고로 set -e 는 POSIX 표준이다.

#! /bin/bash

set -e
[ condition ] && cmd1
echo "hello"

두번째로는 || true 로 false 인 경우도 추가하여 아무동작도 수행하지 않는것이다.

#! /bin/bash

[ condition ] && cmd1 || true
echo "hello"

이렇게 하면 condition이 false더라도 해당 스크립트가 비정상 종료 되지 않고 echo "hello"가 출력된다.

If Statement의 작동원리

if
   cmd1
then
   cmd2
else
   cmd3
fi

이제 쉘스크립트의 If Statement 를 정확히 알아보자. 중요한점은 If 바로 다음에는 명령어가 온다는것이다. 여기에는 보통 []로 표현되는 test명령을 사용하지만 이전에 설명했드시 일반 명령어를 사용할수도 있다. 그렇다면 then이 하는 역할은 무엇인가? then이 바로 이전명령의 exit status를 포착하는 역할이다. 이전 exit status가 0 인경우에 then state의 구문이 수행되는 것이다. 따라서 위의 예에서 cmd1 이 exit code 0을 리턴하면 cmd2 가 수행되고 1 이상의 값을 리턴하면 cmd3이 수행된다. 참고로 우리가 이미 알고있듯이 많은 쉘스크립트가 if cmd1; then 과 같이 한줄로 표기한다. ;는 명령어 뒤에 붙으며, 다음명령까지 한줄에서 처리하게 만드는 역할을 한다.

References

GNU autotools 로 UNIX스럽게 프로젝트 구성하기

Sat, 11 Sep 2021 13:00:00 +0000

빌드 시스템
TL;DR
소스코드 작성
autoconf
aclocal
automake
autoreconf
프로젝트 배포하기
생성한 프로젝트 빌드 및 설치 해보기
실행파일 생성!
요약
References

빌드 시스템

프로젝트의 소스코드가 한두개가 아니라 수십 수만개가 되면 gcc 로 일일이 컴파일을하여 하나의 executable 실행파일로 생성하는것은 불가능하다. 이를 위해 make 빌드시스템이 고대에 도입되었다(It was originally created by Stuart Feldman in April 1976 at Bell Labs.). make는 Makefile이라는 파일을 이용해 소스코드를 컴파일하고 빌드한다. Makefile은 컴파일을 위한 쉘스크립트라고 보면 쉽다. 일반 쉘스크립트를 이용해 빌드환경을 만들수 도 있다. 그러나 보통 쉘스크립트는 빌드환경에 특화되어있지 않기 때문에 거의 사용하지 않는다. 참고로 쉘스크립트와 Makefile 스크립트의 다른점 중 하나는 Increamental Build인데, 기존에 빌드를 진행한적이 있다면, 그 뒤에는 make가 최근 수정된 소스코드만 컴파일하여 최종 executable에 링크하는 를 할 수 있다.

또한 소스코드의 파일이 방대한경우 그리고 빌드하는 환경이 유저마다 서로 다른경우, 또한 여러가지 기능들을 사용자가 추가/제거 하고 싶은경우 Makefile에서 모든것을 처리하는게 쉬운일은 아니다. 그래서 대부분의 UNIX 유틸리티의 소스코드 패키지에는 autotools 로 생성한 configure파일 그리고 Mafefile.am파일이 존재해서 사용자가 직접 본인의 UNIX 환경에서 Makefile을 생성하게끔 한다. GNU autotools는 이렇게 불편을 최소화하기 위해 소스코드 패키지를 여러 UNIX계열 시스템에 이식성(portable)가능하게 만들어주는 도구다. 다시말해 이식성 가능한 프로젝트 빌드를 가능하게 해주는 도구다.

make는 거의 무려 50년전에 만들어진 소프트웨어이기 때문에 현대의 빠른 빌드를 요구하는 환경에는 적합하지 않을수도 있다. 그래서 여러가지 빌드시스템이 만들어졌고 사용되고 있다.

Cmake
Ninja (Chromium, Andriod Soong빌드 등)
Meson (Systemd 등)
Cargo (Rust)

거의 대부부분의 UNIX 유틸리티는 빌드할때 아래와 같은 과정을 거치도록 만들어졌다. ./configure로 옵션으로 전달받은 Feature를 추가/제거하고 현재 호스트의 운영체제와 환경등을 고려하여 Makefile 을 생성한다. make 로 실제 소스코드를 빌드하고. make install로 사용자의 환경에 install한다(실행파일과 라이브러리등을 적절한 path에 배치한다). 가령 grep-3.7 의경우 이렇게 빌드한다.

 $ ./configure
 $ make
 $ make install

UNIX 유틸리티중 하나를 찾아서 소스코드를 다운로드 받아보자(Grep-3.7 다운로드). 소스코드 압축을 풀면 configure 파일이 존재한다. 이는 Makefile을 생성하는 쉘스크립트이다. 나는 소스코드에서 configure 파일의 라인수를 보고 내 두 눈을 의심했다. 파일이 5만 라인이 넘었기 때문이다. 이걸 인간이 짤 수 있다는 말인가? 유틸리티 소스코드도 작성하기 힘든데 빌드시스템을 위해 이렇게 많은 스크립트를 작성해야 한다는 말인가? 하는 생각들에 아찔해졌다. 하지만 파일 상단 주석에 이렇게 쓰여있었다. Generated by GNU Autoconf 2.71 for GNU grep 3.7. 다행히도 configure 스크립트는 자동생성 되는것이다. 바로 autoconf 라는 프로그램이 자동으로 생성해준다. autoconf가 얼마나 많은 라인을 만들어내는지 간단한 autoconf 스크립트를 작성해 실험해보자.

먼저 디렉터리 하나를 생성하고 autoconf.ac 라는 파일을 생성하여 아래의 두 줄을 작성한다. autoconf.ac 이 configure 파일을 생성하기 위해 사용자가 작성해야할 파일이다. 자세한 내용은 아래에서 다시 설명할 것이다.

AC_INIT([helloworld], [0.1])
AC_OUTPUT

그리고 Shell에서 autoconf 프로그램을 실행한다. 그러면 아래와 같이 configure 파일이 생성된것을 알 수 있다.

 $ aclocal
 $ autoconf
 $ ls
autom4te.cache  configure  configure.ac

그리고 configure파일을 열어서 확인해 보자. 고작 두줄짜리로 부터 얼마나 많은 라인의 configure스크립트가 자동생성되었는지… (나는 2402라인이 생성되었다.).

TL;DR

이제 autotools 를 이용해 간단한 helloworld 프로그램의 소스코드 패키지 레이아웃을 UNIX스럽고 프로페셔널 해보이게(?) 구성해보자. 결론부터 이야기하면 GNU autotools 에서 사용하는 도구는 다음과같이 두가지다.

configure.ac 파일로 부터 configure 파일 생성 명령어
```
 $ autoconf
```
Makefile.am 파일로 부터 Makefile.in 생성 명령어
```
 $ automake --add-missing
```

소스코드 작성

먼저 소스코드를 작성해보자. 이 예제에서는 간단하게 helloworld.c 하나를 작성했다.

#include <stdio.h>

int main(int argc, char *argv[])
{
    printf("hello, world!\n");
    return 0;
}

autoconf

autoconf는 configure 스크립트를 자동생성해주는 도구다. autotools 는 m4 매크로 패턴을 사용한다. 아래와 같이 매크로를 사용해 최소한의 정보를 입력해보자.

AC_INIT([helloworld], [0.1], [jihuun.k@gmail.com])
AM_INIT_AUTOMAKE
AC_PROG_CC
AC_CONFIG_FILES([Makefile])
AC_OUTPUT

AC_INIT autoconf 에게 생성할 프로그램 이름, 그리고 버전정보, 그리고 누가 maintainer인지 알려준다.
AM_INIT_AUTOMAKE automake도 사용할 예정이라면 추가한다.
AC_PROG_CC 사용자의 현재 환경의 C 컴파일러를 사용하도록 설정한다.
AC_CONFIG_FILES AC_CONFIG_FILES([filename]) 은 filename.in 파일로부터 filename파일을 생성한다는 의미다.
AC_OUTPUT 최종 output을 생성한다는 의미 configure.ac 스크립트의 마지막에 위치한다.
보다 자세한 autoconf 매크로 정보는 GNU autoconf manual에서 확인가능하다. https://www.gnu.org/software/autoconf/manual/autoconf-2.66/autoconf.html

그 뒤에 아래와 같이 autoconf 명령을 수행하면 configure파일이 생성된다.

 $ aclocal
 $ autoconf
 $ ls
autom4te.cache  configure  configure.ac

aclocal

한편 autoconf 명령을 사용하기 전에 aclocal 명령어를 통해 사전에 환경을 설정해줘야한다. aclocal 명령을 수행하면 aclocal.m4 파일이 생성된다. 그 뒤 autoconf 수행하면 configure 파일을 생성할 수 있다. 참고로 aclocal을 하지 않으면 아래와 같은 에러가 발생한다.

 $ autoconf
configure.ac:2: error: possibly undefined macro: AM_INIT_AUTOMAKE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
 $ aclocal
 $ autoconf

automake

automake는 Makefile.am 파일로부터 Makefile.in 파일을 생성하는 도구이다.

Makefile.am 생성

AUTOMAKE_OPTIONS  = foreign
bin_PROGRAMS = helloworld
helloworld_SOURCES = helloworld.c

AUTOMAKE_OPTIONS = foreign GNU 프로젝트의 Standard Layout을 따르지 않을거라면 추가한다.
bin_PROGRAMS = programname 생성할 실행파일(프로그램) 이름을 기입한다.
programname_SOURCES = srcfilename.c 소스코드 파일명을 기입한다.

이제 automake를 수행하면 Makefile.in 이 생성된다.

 $ automake --add-missing

참고–add-missing 사용하는 이유: automake 는 특정상황에 따라 여러가지 common파일들을 요구한다. 이 옵션을 사용하면 그파일들을 자동생성해준다.
참고 AUTOMAKE_OPTIONS = foreign 이 없을때 발생하는 에러 GNU 프로젝트의 standard Layout 을 추가하지 않아서 에러가 발생한다. 아래와 같은 파일들이 생성되어야 한다.

$ automake --add-missing
configure.ac:3: installing './compile'
configure.ac:2: installing './install-sh'
configure.ac:2: installing './missing'
Makefile.am: installing './INSTALL'
Makefile.am: error: required file './NEWS' not found
Makefile.am: error: required file './README' not found
Makefile.am: error: required file './AUTHORS' not found
Makefile.am: error: required file './ChangeLog' not found
Makefile.am: installing './COPYING' using GNU General Public License v3 file
Makefile.am:     Consider adding the COPYING file to the version control system
Makefile.am:     for your code, to avoid questions about which license your project uses
Makefile.am: installing './depcomp'

최종 생성된 파일들

 $ ls
aclocal.m4  autom4te.cache  compile  configure  configure.ac  COPYING  depcomp  helloworld.c  INSTALL  install-sh  Makefile.am  Makefile.in  missing

autoreconf

참고로 autoreconf를 사용하면 aclocal, autoconf 및 automake를 직접 하나하나 수행할 필요없다. 알아서 한번에 수행해준다.

 $ autoreconf -i

프로젝트 배포하기

이제 드디어 configure 스크립트와 Makefile.in 파일이 우리 프로젝트에 생성되었다. 이제 소스코드를 다운로드 받은 사용자는 configure 와 make 를 사용해 프로젝트를 빌드 할 수 있다. 프로젝트는 이상태에서 배포가능하다. make dist를 수행하면 배포가능한 tarball이 생성된다.

 $ make dist
 $ ls

또한 다음과 같이 배포할 tarball이 여러 환경과 조건에서 정상적으로 install될 수 있을지 테스트해볼 수 있다.

 $ make distcheck

생성한 프로젝트 빌드 및 설치 해보기

이제 아래의 UNIX 빌드 명령으로 프로젝트 빌드를 해보자. configure 실행하여 Makefile을 생성하고 make를통해 빌드해보자.

 $ ./configure
 $ make
 $ make install

 $ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands

 $ make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/jihuun/project/c_language/autotools_test/missing autoconf
/bin/sh ./config.status --recheck
running CONFIG_SHELL=/bin/sh /bin/sh ./configure --no-create --no-recursion
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking that generated files are newer than configure... done
configure: creating ./config.status
 /bin/sh ./config.status
config.status: creating Makefile
config.status: executing depfiles commands
gcc -DPACKAGE_NAME=\"helloworld\" -DPACKAGE_TARNAME=\"helloworld\" -DPACKAGE_VERSION=\"0.1\" -DPACKAGE_STRING=\"helloworld\ 0.1\" -DPACKAGE_BUGREPORT=\"jihuun.k@gmail.com\" -DPACKAGE_URL=\"\" -DPACKAGE=\"helloworld\" -DVERSION=\"0.1\" -I.     -g -O2 -MT helloworld.o -MD -MP -MF .deps/helloworld.Tpo -c -o helloworld.o helloworld.c
mv -f .deps/helloworld.Tpo .deps/helloworld.Po
gcc  -g -O2   -o helloworld helloworld.o

실행파일 생성!

이제 helloworld 실행파일이 생성되었다.

 $ ./helloworld
hello, world!

이제 make install 하면 현재 환경변수에 실행파일이 등록되어, 어느 위치에서든 helloworld 프로그램을 실행 시킬수 있다.

 $ make install
 $ helloworld
hello, world!

참고로 최종 생성된 파일은 다음과 같다. 오지게 많다.

 $ ls
aclocal.m4  autom4te.cache  compile  config.log  config.status  configure  configure.ac  COPYING  depcomp  helloworld  helloworld.c  helloworld.o  INSTALL  install-sh  Makefile  Makefile.am  Makefile.in  missing

요약

위의 내용을 정리하면 다음과 같다.

프로젝트 생성자 관점

 $ aclocal # m4 환경 생성
 $ autoconf # configure.ac 파일로 부터 configure 스크립트 생성
 $ automake --add-missing # Makefile.am 로부터 Makefile.in 생성
 $ make dist # 배포용 tarball생성
 $ make distcheck # 배포용 tarball 테스트

사용자 관점 빌드 해당 프로젝트 소스코드를 다운받고 본인의 환경에 설치하는 사람들은 다음의 절차를 수행할 것이다.

 $ ./configure # Makefile.in로부터 Makefile생성
 $ make # 전체 프로그램 빌드
 $ make install # 프로그램 설치, 실행 파일 및 라이브러리 등을 배치

References

Publishing my project to Homebrew

Sun, 05 Sep 2021 13:00:00 +0000

1. 개요
2. Homebrew에 프로젝트 등록하기
- 2.1. 내 프로젝트 바이너리 생성 및 release
- 2.2. homebrew-rsdic Github repo 생성
3. 패키지 설치해보기
4. 추후 릴리즈 자동화

1. 개요

UNIX 계열 운영체제는 각각 여러가지 Package Manager가 존재한다. 우분투 같은 Debian 계열의 리눅스 배포판은 APT-based package management 도구를 제공한다. Red Hat계열의 리눅스 배포판에서는 RPM이라는 Package Manager를 제공한다. Package Manager 종류에 대한 자세한 내용은 위키피디아 문서를 참고. MacOS 에서는 Homebrew라는Package Manager를 많이 사용하는데. Homebrew에 내가만든 소프트웨어를 Publish하여 사람들이 쉽게 내 소프트웨어를 다운받고 설치할수 있게 만들어보자. 내가 조사한 바로는 아래와 같이 두 가지 방법이 있다.

Homebrew-core 에 등록
brew install <my-project> 로 설치가능하게 되는 공식적인 방법. homebrew-core github repo에 Pull Request를 보내면 되는듯 하다. 자세한 내용은 다음의 Documentation를 참고하면 된다. Adding-Software-to-Homebrew
Brew tap 으로 설치
homebrew 공식 릴리즈에 포함되지 않더라도 등록할 수 있는 방법이다. 결과는 brew tap 으로 repo를 추가할수 있게된다. 참고로 Tap 은 homebrew에서 제공하는 third-party 저장소를 등록하는 방법이다. 등록 이후에 아래와 같은 방법으로 해당 소프트웨어를 설치 할 수 있다. 참고 문서: https://federicoterzi.com/blog/how-to-publish-your-rust-project-on-homebrew/
```
  $ brew tap jihuun/rsdic
  $ brew install rsdic
```

이 문서에서는 2번 방법에대해 알아볼 것이다. 예제로 사용한 Publish 대상은 내가 만든 터미널용 영어사전인 rsdic이다. 이 프로젝트는 Rust로 작성되었으며 이 문서에는 Rust 관련 내용이 일부 포함될 수 있다.

2. Homebrew에 프로젝트 등록하기

2.1. 내 프로젝트 바이너리 생성 및 release

*.tar.gz 압축파일 생성
조금 뒤에 살펴볼 homebrew Formula에서 *.tar.gz 로 압축된 바이너리를 필요로한다. 우선 프로젝트를 빌드하여 실행파일을 생성한 뒤에 *.tar.gz로 압축 하면된다. Rust에서는 cargo build --release 하면 쉽게 릴리즈 바이너리를 빌드할 수 있다.
```
  cargo build --release
  cd target/release
  tar -zcvf rsdic.tar.gz rsdic
```
sha256 해시 생성
생성한 압축파일에 대한 해시값도 추후 homebrew Formula에 추가해야 한다. 빠르게 검색하기 위한 용도인듯 하다.
```
  $ shasum -a 256 rsdic.tar.gz
  f65f3265654fd662fd37334122cd2f97f3b85de12969dae81d0484f30cebeceb  rsdic.tar.gz
```
바이너리 링크 생성
Github Release에 .tar.gz 바이너리 업로드 하고 아래와 같은 링크를 생성한다. https://github.com/jihuun/rsdic/releases/download/v0.1.0/rsdic.tar.gz

2.2. `homebrew-rsdic` Github repo 생성

homebrew-rsdic Github repo 생성
Github repository를 하나 생성한다. 저장소 이름은 homebrew-<projectname> 와 같은 방식으로 해야한다. 자세한 이유는 Homebrew 네이밍 컨벤션 참고.
Formula 작성
Formula는 Ruby 파일인데 딱히 Ruby지식을 필요로 하지는 않는다(나도 모름). 생성한 repository는 아래와 같은 디렉터리 구조를 필요로 한다.
```
  - Formula/
      - <projectname>.rb
  - README.md
```

Formula/rsdic.rb 생성
Formula/rsdic.rb 파일을 생성하고 아래의 내용을 추가한다.

  # Documentation: https://docs.brew.sh/Formula-Cookbook
  #                https://rubydoc.brew.sh/Formula
  # PLEASE REMOVE ALL GENERATED COMMENTS BEFORE SUBMITTING YOUR PULL REQUEST!
  class Rsdic < Formula
    desc "A eng-kor dictionary for the terminal users"
    homepage "https://github.com/jihuun/rsdic"
    url "https://github.com/jihuun/rsdic/releases/download/v0.1.0/rsdic.tar.gz"
    sha256 "f65f3265654fd662fd37334122cd2f97f3b85de12969dae81d0484f30cebeceb"
    version "0.1.0"

    def install
      bin.install "rsdic"
    end
  end

commit 생성하고 push
여기까지 하면 Homebrew를 통해 내 프로젝트를 다운로드 받을 수 있다. 실제 커밋 참고. https://github.com/jihuun/homebrew-rsdic/commit/a02f6db3f50a5111ade52e2f31f3c963f97db844

3. 패키지 설치해보기

brew tap 으로 third party repo등록

   $ brew tap jihuun/rsdic

  ==> Tapping jihuun/rsdic
  Cloning into '/usr/local/Homebrew/Library/Taps/jihuun/homebrew-rsdic'...
  remote: Enumerating objects: 5, done.
  remote: Counting objects: 100% (5/5), done.
  remote: Compressing objects: 100% (4/4), done.
  remote: Total 5 (delta 0), reused 5 (delta 0), pack-reused 0
  Unpacking objects: 100% (5/5), done.
  Tapped 1 formula (29 files, 24.2KB).

Package install

   $ brew install rsdic

  ==> Installing rsdic from jihuun/rsdic
  ==> Downloading https://github.com/jihuun/rsdic/releases/download/v0.1.0/rsdic.tar.gz
  ==> Downloading from https://github-releases.githubusercontent.com/364442112/3c316f00-adc4-11eb-88cd-b249eab44c28?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Crede
######################################################################## 100.0%

4. 추후 릴리즈 자동화

이제 새 버전 릴리즈시 homebrew-rsdic repo에서 rsdic.rb 파일에 내용을 업데이트 하여 반영하면 된다. Travis 같은 CI/CD 툴로 버전 릴리즈후 brew에 바이너리 업데이트 과정을 자동화 하면 좋을 것 같다.

Bash Auto Completion

Thu, 02 Sep 2021 13:00:00 +0000

개요
목표
기초
complete 명령 사용법
COMP_CWORD 와 COMP_WORDS로 인자 다루기
COMPREPLY 전역변수 사용하기
compgen 사용하기
최종 완성
References

개요

bash 쉘에서 본인이 작성한 스크립트나 프로그램 명령에 argument를 입력할때, TAB으로 자동완성 시켜주는 기능을 만들어보자

목표

cdd 전달인자인 경로 자동완성기능 추가하기
cdd는 cd ../../../../ 를 입력하는 대신 cdd 4로 손쉽게 뒤로이동 하는 내가 만든 명령도구다.
cdd 바로가기: https://github.com/scriptworld/cdd
cdd 3 + TAB 을 쳤을때 ../../../ 경로의 디렉터리 이름 출력 및 prefix로 디렉터리 자동완성

기초

bash completion 을 만들때, 기본적으로 이 두가지 외부 툴(명령)이 함께 사용된다. complete compgen
그리고 내부 변수 COMPREPLY, COMP_CWORD, COMP_WORDS 를 활용한다. 이들을 잘 조합한 bash스크립트로 자동완성 기능을 만들 수 있다.

강추 문서 https://mug896.github.io/bash-shell/command_completion.html

complete 명령 사용법

complete -F <함수> <명령> : 쉘에서<명령> 작성 후 한칸 띄고 `TAB`치면 <함수> 호출된다. 엔터가 아니라 탭을 쳤을때 사용되는 추가 명령 이라고 보면 될것같다.

cdd/completion/bash_cdd 생성

#!/bin/bash

_cdd()
{
    echo 'auto completion test'
}
complete -F _cdd cdd 

심볼릭링크 생성 (MacOS: /usr/local/etc/bash_completion.d)

 $ ln -s ~/project/cdd/completions/bash_cdd /usr/local/etc/bash_completion.d/cdd
 $ source /usr/local/etc/bash_completion.d/cdd

그 뒤 cdd 3 + TAB하면 작성한 _cdd 함수가 동작하는것을 알 수 있다. 따라서 앞으로 _cdd() 함수에 원하는 동작을 작성하면 된다.

$ cdd 3 auto completion test

그 뒤 엔터를 치면 실제 cdd명령 수행됨 go to ./../../../

complete -o dirnames 옵션

TAB 하면 디렉터리 이름을 자동완성 한다.

$ complete -o dirnames hello 
$ hello [TAB]
aa/ bb/ cc/

-W 옵션 자동완성 되기 원하는 옵션이나 문구등을 지정할 수 있다. 띄어쓰기로 구분되고 출력은 자동정렬되어 나온다.

$ complete -W '-a -b -c' hello
$ hello [TAB]
-a -b -c

-o nospace 옵션 이름을 자동완성하고 나면 다음 이름을 위해 공백을 띄우게 되는데, 이 옵션은 그걸 방지.
가령 아래 예시에서 hello a까지 입력하고 TAB을 치면 hello aaa=가 자동완성 되고 커서가 마지막 = 바로뒤에 멈춘다.

$ complete -o nospace -W 'aaa= bbb= ccc=' hello
$ hello aaa=

COMP_CWORD 와 COMP_WORDS로 인자 다루기

int main(int argc, char *argv[]) 의 인자와 동일한 역할

$COMP_CWORD -> int argc argument 갯수 $COMP_WORDS -> char *argv[] 모든 argument 문자열 리스트

TAB 을 칠때, cdd명령으로 전달되는 인자 확인

#!/bin/bash

_cdd()
{
    echo ''
    echo 'argument count : '$COMP_CWORD
    echo 'argument words0 : '${COMP_WORDS[0]}
    echo 'argument words1 : '${COMP_WORDS[1]}
    echo 'argument words2 : '${COMP_WORDS[2]}
}
complete -F _cdd cdd 

$ cdd 3 
argument count : 2
argument words0 : cdd
argument words1 : 3
argument words2 : 

cdd 3 space를 치고 TAB을 친 경우임. 만약 cdd 3 뒤에 space를 치지 않고 TAB을 치면 argument count : 1 이 된다.

COMPREPLY 전역변수 사용하기

TAB을 쳤을때 COMPREPLY에 저장된 문자열로 대체된다. 우리가 최종에 값을 저장해야할 변수. bash_completion의 내장 변수.

#!/bin/bash

_cdd()
{
    COMPREPLY='aabbcc'
}
complete -F _cdd cdd 

그 뒤 cdd + TAB을 하면 aabbcc가 자동으로 대체된다. 아무문자를 입력하고 TAB해도 바뀐다. 가령 $ cdd efTAB 하면 -> $ cdd aabbcc 로 바뀜

따라서 cdd 뒤에 오는 인자에 따라 COMPREPLY 값을 바꿔주면 될듯!

가령 cdd 3 하고 (스페이스를 치지 않고 바로) TAB을 치면, 아직 인자를 전달한것이 아니기 때문에 $COMP_CWORD 이 2가 아니라 1이다. 하지만 작성중인 인자 3은 ${COMP_WORDS[1]} 에 저장되어 있다.

argument count : 1 argument words0 : cdd argument words1 : 3

이를 이용하면 ${COMP_WORDS[1]가 3인 경우에, COMPREPLY에 “../../../”을 저장하면, $ cdd ../../../ 로 대체되게 만들수 있다! 그리고 내부적으로 ../../../ 경로의 실제 디렉터리를 자동완성으로 출력하거나 변환하면 된다. (하지만 현재 cdd 로는 이 기능 수행못함, cdd명령 추가구현 필요)

cdd 내부 동작 수정해야할 내용

cdd 인자로 숫자들어오는 경우 -> 기존 cdd내용 수행

cdd 인자로 경로들어오는 경우 -> 일반 cd 경로 수행 참고: 숫자 문자 구분 방법: https://stackoverflow.com/questions/806906/how-do-i-test-if-a-variable-is-a-number-in-bash/806923 숫자/문자로 구분하는게 아니라 전달받은 인자가 exist한 directory인지 아닌지로 구분이 더 나을듯?

compgen 사용하기

compgen -W '단어1 단어2 ... 단어N' -- "<Prefix>"

단어 중에서 가 포함 되어있는 단어만 출력한다.

$ compgen -W 'soopsaram soopnorm great man' -- 'soop'
soopsaram
soopnorm

$ ls
complate/   test/   aa   bb
$ compgen -W '$(find . -mindepth 1 -maxdepth 1 -type d)' -- "./co"
complate/ 

compgen을 find와 조합해서 디렉터리에 존재하는 경로명을 추출할 수 있다.

최종 완성

_cdd() {
	[[ ${COMP_CWORD} -eq 1 ]] || return 0
	[[ -z ${COMP_WORDS[1]} ]] && COMPREPLY="$(__cdd_prev_path 1)"
	[[ ${COMP_WORDS[1]} =~ ^[0-9]+$ ]] \
		&& COMPREPLY="$(__cdd_prev_path ${COMP_WORDS[1]})"
}
complete -o dirnames -o nospace -F _cdd cdd

cdd 바로가기: https://github.com/scriptworld/cdd

References

All That Stream

Tue, 31 Aug 2021 13:00:00 +0000

1. What is Stream
- 1.1. Stream 과 File
2. Standard Stream (표준 스트림)
3. Stream with C language

1. What is Stream

UNIX에서는 모든것이 file이다. Stream을 사용하는것은 UNIX 응용프로그램에서 파일을 읽고 쓰기 위한 일반적인 방법이기 때문에 UNIX 에서 Stream에 대한 이해하는것은 중요하다.

1.1. Stream 과 File

우선 file과 stream의 차이에 대해 알아보자. file은 바이트의 연속적인 모음이다(sequences of bytes). stream은 이 bytes를 입출력하기 위한 인터페이스이자 도구이다. stream은 file뿐만 아니라 socket, keyboard, USB port, printer등 sequential data 로 이루어진 데이터를 다루기 위한 common 인터페이스인데, 이 하나의 인터페이스로 모든 소스를 다룰 수 있다. 모든 소스를 단일한 인터페이스로 다룰 수 있기 때문에 동일한 코드로 위에 나열된 장치들을 모두 file로 여기고 읽고 쓸수 있게 된다. 다시말하지만 UNIX에서는 모든것이 file이다.

stream은 모든 입력 출력을 바이트의 흐름으로 생각하는것이다. 입출력 장치, 하드웨어, 단말에 상관없이 프로그램을 작성할수 있는 독립성을 갖는다. 이를 장치독립성이라고 한다. 그리고 입출력장치와 CPU의 속도차이를 보완하기 위해서 버퍼를 갖는다.

아직 Stream의 정체가 무엇인지 매우 추상적이고 모호하다. 그렇다면 물리적으로 Stream은 어떻게 표현될까? C언어에서 Standard Library 함수인 fopen() 을 사용해 file을 열어보면, 해당 함수는 FILE * 이라는 struct FILE의 포인터 타입을 리턴한다. 이것이 Stream이다(file stream). FILE * 포인터는 실제 파일을 가리키는 포인터가 아니다. 파일의 스트림을 가리키는 포인터이다. 그리고 그 스트림에는 파일에 대한 여러가지 정보가 담겨있다.

stream에는 standard stream이 있는데 이것도 결국 file 에 대한 stream이다. 모두 file descriptor 번호를 가지고 있다. standard stream은 프로그램이 실행되면 OS에서 자동으로 생성한다 (stdin/stdout/stderr). stdin 은 FILE * 타입으로 stdio.h 에 정의되어있다. 자세한 내용은 챕터 2에서 다시 설명한다.

vi나 nano같은 에디터로 파일을 열면 에디터 프로그램은 해당 파일의 스트림을 생성하고 읽고 쓴다.

references

stackoverflow: what-does-stream-mean-in-c youtube: 스트림 (널널한 교수의 기초 C언어) ft. C 코딩

2. Standard Stream (표준 스트림)

2.1. Standard Streams: `stdin` , `stdout`, `stderr`

프로그래머가 생성하지 않아도 자동으로 생성되는 스트림. 모든 Process에 각각 생성된다. 프로그램이 실행되면 운영체제는 실행되는 프로그램(프로세스)에게 3개의 기본 file descripter 를 할당해준다. 번호는 stdin:0 , stdout:1 , stderr:2. 그리고 만약 프로그램이 내부에서 다른 파일을 open() 하게 되면 운영체제는 해당 프로세스에게 3번 file descripter를 할당한다. stdin , stdout, stderr 모두 FILE * 타입으로 stdio.h 에 정의되어있다.

the OS gives the address to the standard stream made for a process to it automatically.
Standard stream 은 Unix C runtime environment 에서 환경을 제공한다. Since Unix provided standard streams, the Unix C runtime environment was obliged to support it as well. As a result, most C runtime environments (and C’s descendants), regardless of the operating system, provide equivalent functionality.
references

https://stackoverflow.com/questions/38652953/what-does-stream-mean-in-c https://blogger.pe.kr/369

2.2. Shell I/O Redirect 와 PIPE 의 차이

일반적으로 UNIX shell은 stdout으로 전달된 것을 console로 출력해준다. 그런데 shell 에서 > 를 사용하면 stdout을 console이 아닌 파일에 출력할 수 있다(stdout to the file). 가령 아래와 같이 ` echo “a b c d”`의 stdout 이 console로 출력되지 않고 tmp.txt 파일로 출력된다. 즉 tmp.txt 파일에 써진다.

 $ echo "a b c d" > tmp.txt
 $ cat tmp.txt 
a b c d

1> 기본적으로 > 와 동일 fd 1번인 stdout 을 stdout으로 redirect. 문법은 file_descriptor > file_name
2> fd 2번인 2번 stream. 즉 stderr를 stdout으로 redirect.
&> &>name 은 1>name 2>name 와 같다. 하지만 name을 두번 open하기 때문에 좋지 않다.
2>&1 아래 에서 따로 설명한다. 결론적으로 stderr를 stdout으로 지정하는의미.

반면 pipe | 는 stdout을 다른 프로그램의 stdin으로 사용할 수 있다. pipe는 아래와 같이 실행하면 ` cat tmp.txt 의 stdout 출력결과가 wc -w 의 stdin으로 입력된다. tmp.txt에 a b c d 즉 4개의 word가 있기때문에 wc -w`하면 4가 출력된다.

 $ cat tmp.txt | wc -w
4

한편 < 를 사용하면 keyboard가 아닌 < 다음 입력된 파일로 부터 stdin 입력된다. 순서는 딱히 상관 없음.

 $ wc -w < tmp.txt
4
 $  < tmp.txt wc -w
4

	요약
`>` file	stdout을 console 이 아닌 file에 출력
`<` file	keyboard가 아닌 file로 부터 stdin 입력
cmd1 `\|` cmd2	한 프로그램(cmd1)의 stdout출력을 다음 프로그램(cmd2)의 stdin 으로 사용

references

https://thoughtbot.com/blog/input-output-redirection-in-the-shell https://github.com/kennyyu/bootcamp-unix/wiki/stdin,-stdout,-stderr,-and-pipes

2.3. `2>&1` 이해하기

Shell 에서 error 메시지를 없앨때 빈번히 사용하는 표현이다. 2> 는 stderr을 stdout으로 redirect. &1 는 이전에 지정한 stdout이 출력하는 파일을 의미한다고 생각하면 쉽다. 엄밀히 말하면 >연산자 대신에 >& 를 사용한것이다. 2>&1 이전에 fd번호 1을 다른 파일로 재지정 했다면, fd번호 2는 재지정한 stdout으로 redirect 한다는 의미.

예를들어, cat asdf.txt 이 아래와 같이 에러메시지를 출력한다고 해보자.

$ cat asdf.txt
cat: asdf.txt: No such file or directory

cat asdf.txt > /dev/null 2>&1 을 수행하면 먼저 stdout은 /dev/null 로 redirect되고, 그 뒤 2>&1을 통해 stderr는 &1로 redirect된다. 즉 stderr도 /dev/null로 redirect되는것이다. 따라서 console에는 아무것도 출력되지 않는다.

그런데 만약 cat asdf.txt 2>&1을 하면 어떻게 될까? stdout 을 따로 지정하지 않았기 때문에 &1 는 default인 console이다. 따라서 2> 즉 stderr 는 그대로 console에 출력된다.

관련해서 구체적인 문법은 아래와 같다. 두번째 항목을 보면된다. >& 연산자의 우측에는 file descriptor 번호가 오는것.

> file_descriptor > file_name
>& file_descriptor >& file_descriptor
&> &> file_name

3. Stream with C language

fopen(), open() 의 차이

가장 큰 차이는 fopen() 은 Standard Library이고, open()은 UNIX System Call이라는 점이다. fopen은 내부적으로 open을 사용한다. fopen은 버퍼를 사용하기 때문에 빈번한 system call 을 방지해준다. 잦은 system call은 성능 저하를 발생시킬 수 있다.

struct FILE 구조체

c:linenumbers,wraptext
typedef strut _iobuf {
        int cnt;        /* characters left */
        char *ptr;      /* next character position */
        char *base;     /* location of buffer */
        int flag;       /* mode of file access */
        int fd;         /* file descriptor */
} FILE;

from K&R (C Programming Language, ANSI C, p.176)

File Pointer vs File Descripter

file pointer는 파일 스트림 포인터 즉 FILE *를 의미한다. file descripter는 OS레벨에서 해당 파일스트림을 구분하기 위한 번호이다. OS가 생성한다.

C 프로그램에서 외부 입출력

stdin/stdout으로 입출력하거나, argument로 입력받는 방법들 비교.

fopen() c프로그램 내에서 파일로부터 파일 스트림 생성.

File Stream에 쓰기 (파일)

fopen을 통해 file.txt 파일의 파일 스트림 포인터 fw를 얻고, fprintf를 통해 write.

        FILE *fp = fopen("file.txt", "w");
        fprintf(fp, "%s %d\n", "hello", 23);
        fclose(fp);

컴파일하고 실행하면, file.txt파일내에 값이 쓰여있다.

$ cat file.txt
hello 23

File Stream에 쓰기 (STDOUT)

반면 아래와 같이 stdout에 write하면

        FILE *fp = stdout;
        fprintf(fp, "%s %d\n", "hello stdin", 100);

혹은

        fprintf(stdout, "%s %d\n", "hello stdin", 100);

(사실 printf는 fprintf(stdout 과 동일하다. )

컴파일 후 실행시 stdout, 즉 콘솔화면에 출력된다. 참고로 stdout은 stdio.h에 정의되어있으며, stdout 스트림은 fclose()로 종료하면 안된다.

$ ./run
hello stdin 100

File Stream 으로부터 입력받기 (STDIN)

        char str[10];
        int num;

        FILE *fp = stdin;
        fscanf(fp, "%s %d", str, &num);
        printf("> %s %d\n", str, num);

pipe 통해서

 $ echo "test_string 99" | ./run
> test_string 99

redirect 를 통해 파일로부터

 $ cat file.txt
hello 23
 $ ./run < file.txt
> hello 23

Argument 로부터 입력받기

int main(int argc, char *argv[])
{
        for (int i = 0; i < argc; i++)
                printf("argument [%d]: %s\n", i, argv[i]);
....

컴파일후 생성된 executable파일 run을 실행하면

$ ./run --option hello world
argument [0]: ./run
argument [1]: --option
argument [2]: hello
argument [3]: world

Documentudy

Red-Black Tree in Linux Kernel - Part 2

사용법 및 구조체 분석

Linux Kernel RB Tree API 사용법 요약

rb_node 구조체

rbtree가 적용된 노드 구조체

root 노드 생성

삽입과 삭제 연산에서 자주 사용하는 내부API 정리

주요 define

rb_entry()

rb_red_parent(red)

rb_set_parent_color(rb, p, color)

rb_set_parent(rb, p)

__rb_rotate_set_parents(old, new, ..., color)

__rb_change_child(old, new, parent, ...)

삽입 연산

__rb_insert() 분석

삭제 연산

__rb_erase_augmented() 분석

____rb_erase_color() 분석

References

Red-Black Tree in Linux Kernel - Part 1

Red-Black Tree 란?

RB tree의 5가지 규칙

삽입 연산

삭제 연산

삭제되는 노드 처리

후계자 노드 처리

References

If 없이 Shell Script 분기 처리하기

Exit Status란 무엇인가

IF없이 커맨드 분기 처리

대괄호[]의 정체

IF 없이 조건 분기 처리

If Statement의 작동원리

References

GNU autotools 로 UNIX스럽게 프로젝트 구성하기

빌드 시스템

TL;DR

소스코드 작성

autoconf

aclocal

automake

autoreconf

프로젝트 배포하기

생성한 프로젝트 빌드 및 설치 해보기

실행파일 생성!

요약

References

Publishing my project to Homebrew

1. 개요

2. Homebrew에 프로젝트 등록하기

2.1. 내 프로젝트 바이너리 생성 및 release

2.2. homebrew-rsdic Github repo 생성

3. 패키지 설치해보기

4. 추후 릴리즈 자동화

Bash Auto Completion

개요

목표

기초

complete 명령 사용법

COMP_CWORD 와 COMP_WORDS로 인자 다루기

COMPREPLY 전역변수 사용하기

compgen 사용하기

최종 완성

References

All That Stream

1. What is Stream

1.1. Stream 과 File

2. Standard Stream (표준 스트림)

2.1. Standard Streams: stdin , stdout, stderr

2.2. Shell I/O Redirect 와 PIPE 의 차이

2.3. 2>&1 이해하기

3. Stream with C language

fopen(), open() 의 차이

File Pointer vs File Descripter

C 프로그램에서 외부 입출력

File Stream에 쓰기 (파일)

File Stream에 쓰기 (STDOUT)

File Stream 으로부터 입력받기 (STDIN)

`rb_node` 구조체

`rb_entry()`

`rb_red_parent(red)`

`rb_set_parent_color(rb, p, color)`

`rb_set_parent(rb, p)`

`__rb_rotate_set_parents(old, new, ..., color)`

`__rb_change_child(old, new, parent, ...)`

`__rb_insert()` 분석

`__rb_erase_augmented()` 분석

`____rb_erase_color()` 분석

대괄호`[]`의 정체

2.2. `homebrew-rsdic` Github repo 생성

2.1. Standard Streams: `stdin` , `stdout`, `stderr`

2.3. `2>&1` 이해하기