NClab

안녕하세요, 오늘은 개발자에게 없어선 안될 프로그램!ㅋㅋ

시너지의 설정에 대해 알아보겠습니다.

시너지는 소프트웨어적으로 여러대의  PC의 키보드/마우스를 공유시켜주는 프로그램이 되겠습니다.

일단,

윈도우용 시너지 파일을 받아 설치합니다.

최신 사이트 기준으로 http://synergy-foss.org/pm/projects/synergy/tabs/download

접속하여 각자의 PC의 OS에 맞추어 설치합니다.(우리는 윈도우기준으로 파일을 받아 설치하구요-)


이제 모니터의 위치에 따라 윈도우 피씨를 오른쪽으로 쓸것인지~ 리눅스를 왼쪽으로 쓸것인지~ 방향을 정해주게 됩니다. 이정돈 알아서 하시고~ PASS

그다음 초기페이지로 돌아오시구요, start 버튼을 누르셔서 클라이언트의 접속을 기다리게 합니다


다음은 Client(리눅스) 쪽 설정입니다.

리눅스에서는 synergy를 패키지로 제공하기에,

> yum install synergy

 로 간단하게 설치할 수 있습니다.

그 다음 synergyc 본인IP 를 입력하시면

바로 서버로 접속할 수 있습니다.

이로써 시너지의 기본설정을 모두 마쳤습니다.




PS1. 키보드와 마우스를 제공하는 PC가 Windows 방화벽을 사용 중이라면 아래와 같이 접속하려는 PC에서 에러가 발생할 수 있습니다.


이렇게 "connect to server : address not found for: ****" 에러가 발생한다면 키보드와 마우스를 제공하는 PC의 Windows 방화벽에서 "파일 및 프린터 공유"를 체크하시고 적용하십시오.

안녕하세요, 오늘은 프로젝트 관련하여 LVS 구축에 대한 이론적인 부분을 기술하도록 하겠습니다.


1. LVS 구축  

가상서버를 구성하는 방안에는 그 방식에 따라 크게 3가지 다른 방법으로 구성할 수가 있습니다. NAT 를 이용하는 방법, IP터널링을 이용하는 방법, 다이렉트 라우팅을 이용하는 방법으로 각각의 장단점을 간단히 알아보도록 하겠습니다.

1). NAT 를 이용하는 방법

NAT(Network Address Translation) 방식은 패킷 내의 IP 주소를 변경해 부하 분산을 수행하는 방법입니다. 먼저 클라이언트에게는 로드 밸런서(Load Balancer)의 도메인 네임 또는 IP가 알려져 있습니다. 클라이언트가 이 알려진 도메인 네임이나 IP를 사용해 로드 밸런서에게 서비스 요청 패킷을 전송합니다. 또한 로드 밸런서는 n개의 서버 가운데 하나를 정해진 스케줄링 방법에 의해 선택한 후 패킷 내의 목적지 주소를 해당 서버의 IP로 다시 작성합니다. 리얼 서버는 클라이언트의 요청을 처리한 후, 로드 밸런서에게 응답을 돌려줍니다. 이때 로드 밸런서는 실제 응답의 발신지 주소를 다시 자신의 IP로 변경한 후 클라이언트에 서비스를 제공합니다.   

NAT에 의한 가상 서버의 장점은 실제 서버가 TCP/IP를 지원하는 어떠한 운영체제에서도 운용될 수 있다는 것입니다. 실제 서버는 사적 인터넷 주소체제(private Internet addresses)를 사용할 수 있고 단지 부하 분산기(load balancer)만 하나의 IP 주소가 필요합니다.  

단점은 확장성에 제한이 있다는 것입니다. 서버의 노드수가 수십개로 증가될 경우 병목이 발생할수 있습니다. 왜냐하면 패킷이 들어오고 나갈때마다 부하분산서버에서 패킷을 변경해야하기 때문입니다. 즉 항상 부하분산서버(Director)를 통과합니다. 로드 밸런서는 리얼 서버로 오가는 모든 패킷의 주소를 재작성해야 하므로 병목현상이 발생할 수 있습니다. 따라서 클러스터를 구성할 수 있는 서버의 개수에 제한을 받습니다. 이외에도 로드 밸런서가 다운될 경우 전체 서비스가 중단되는 문제가 발생합니다. 이를 방지하기 위해 일반적으로 ‘백업 로드 밸런서’를 두지만, 평상시는 이 고가의 서버를 사용하지 않으므로 낭비 요소가 됩니다. 방식은 하드웨어나 어플라이언스 형태로 제공되는 경우가 많으며, 대표적인 NAT 방식으로는 레이어4 스위치(OSI 7 계층 모델 가운데 4번 계층인 전송 계층에서 이뤄지는 스위칭 기법을 지원하는 네트워크 장비), 시스코의 로컬 디렉터, LVS(Linux Virtual Server)-NAT 방식 등이 있습니다.

 

 
<Figure 1. NAT 방식>

 

2). IP터널링을 이용하는 방법

IP터널링 방식에서는 NAT방식과는 다르게 부하분산서버는 들어오는 요청에 대해서 뒷단의 서버들(Real Server)에게 패킷을 전달하는 역할만 수행을 합니다. 뒷단의 서버들은 받은 요청에 대해서 다시 부하분산서버로 패킷을 주는 NAT방식과는 다르게 직접 그 요청의 처리를 수행하기 때문에 병목현상이 없어지게 됩니다. 이러한 IP터널링 방식을 설정하기 위해서는 Director 뿐만 아니라 Real Server에서 역시 IP터널링을 지원하도록 설정을 해주어야 합니다.

 

<Figure 2. IP Tunneling 방식>

3). 다이렉트 라우팅을 이용하는 방법

 

다이렉트 라우팅은 리얼 서버와 로드 밸런서가 가상 IP 주소를 공유합니다. 로드 밸런서와 리얼 서버는 네트워크 인터페이스에 가상 IP가 설정돼 있어야 하며, 이 인터페이스를 이용해 로드 밸런서는 요청 패킷을 받아들이고 스케줄링에 의해 선택된 리얼 서버로 직접 라우팅 합니다.

먼저 클라이언트가 가상 IP로 서비스 요청을 하면 로드 밸런서는 리얼 서버 가운데 하나를 스케줄링합니다. 그리고 선택된 서버로 직접 라우팅해 클라이언트의 요청을 리얼 서버로 전달합니다. 리얼 서버는 요청 사항을 처리한 후, 로드 밸런서를 거치지 않고 클라이언트로 직접 응답을 합니다. 각 리얼 서버는 로드 밸런서와 같은 가상 IP를 공유하고 있기 때문에, 로드 밸런서를 거치지 않고 클라이언트로 직접 응답할 수 있습니다.

이 방식은 로드 밸런서에서 병목현상이 NAT보다 적게 나타납니다. 로드 밸런서의 시스템 환경에 따라 차이가 있겠지만, 이론적으로는 100여 개의 서버를 클러스터로 구성할 수 있다고 합니다. 현재 대부분의 운영체제가 가상 IP 설정을 지원하므로 리얼 서버로 사용함에 있어 운영체제에 큰 제한을 받지 않습니다. 하지만 로드 밸런서뿐만 아니라 리얼 서버도 각각의 리얼 IP를 가지고 있어야 합니다. 그리고 NAT와 마찬가지로 백업 서버를 둬야 하는 부담이 있습니다. 특히 리눅스를 리얼 서버로 사용하는 경우 ARP 문제를 해결하기 위해 커널을 수정해 주어야 하는 경우가 있습니다. 참고로 다이렉트 라우팅 방식을 이용한 제품은 Resonate와 터보 클러스터, LVS-DR 등이 있습니다.

 

 

  <Figure 3. Direct Routing 방식>

2. 가상 서버 스케쥴링 알고리즘 

리눅스 가상서버에서 사용하는 스케쥴링 알고리즘을 설명합니다. 

1) Round-Robin Scheduling (라운드 로빈 스케쥴링)

말그대로 라운드-로빈 방식을 이용해 네트웍 연결을 서로 다른 서버에 연결하는 것을 말합니다. 이 경우 실제서버의 연결 갯수나 반응 시간 등은 고려를 하지 않습니다. 그렇지만 약간의 차이가 있습니다. 라운드 로빈 DNS는 단일한 도메인을 서로 다른 IP로 해석을 하지만, 스케쥴링의 기초는 호스트 기반이며 캐싱때문에 알고리즘을 효율적으로 사용하기 힘듭니다. 그래서 실제 서버사이에 동적인 부하 불균형이 심각해 질수 있습니다. 가상 서버의 스케쥴링 기초는 네트웍 기반이며 라운드 로빈 DNS 에 비해 훨씬 더 훌륭합니다.

2) Weighted Round-Robin Scheduling (가중치기반 라운드 로빈 스케쥴링)

가중치기반 라운드 로빈 스케쥴링은 실제 서버에 서로 다른 처리 용량을 지정할 수 있습니다. 각 서버에 가중치를 부여할 수 있으며, 여기서 지정한 정수값을 통해 처리 용량을 정합니다. 기본 가중치는 1입니다.

가중치가 있는 라운드 로빈 스케쥴링을 사용하면 실제 서버에서 네트웍 접속을 셀 필요가 없고 동적 스케쥴링 알고리즘보다 스케쥴링의 과부하가 적으므로 더 많은 실제 서버를 운영할 수 있습니다. 그러나 요청에 대한 부하가 매우 많을 경우 실제 서버사이에 동적인 부하 불균형 상태가 생길 수 있습니다.

  3) Least-Connection Scheduling (최소 접속 스케쥴링) 

최소 접속 스케쥴링은 가장 접속이 적은 서버로 요청을 직접 연결하는 방식을 말합니다. 각 서버에서 동적으로 실제 접속한 숫자를 세어야하므로 동적인 스케쥴링 알고리즘중의 하나입니다. 비슷한 성능의 서버로 구성된 가상 서버는 아주 큰 요구가 한 서버로만 집중되지 않기 때문에, 접속부하가 매우 큰 경우에도 아주 효과적으로 분산을 합니다.

가장 빠른 서버에서 더 많은 네트웍 접속을 처리할 수 있습니다. 그러므로 다양한 처리 용랑을 지닌 서버로 구성했을 경우에도 훌륭하게 작동 한다는 것을 한눈에 알 수 있을 것입니다. 그렇지만 실제로는 TCP의 TIME_WAIT 상태 때문에 아주 좋은 성능을 낼 수는 없습니다.

4) Weighted Least-Connection Scheduling (가중치 기반 최소 접속 스케쥴링)

가중치 기반 최소 접속 스케쥴링은 최소 접속 스케쥴링의 한 부분으로서 각각의 실제 서버에 성능 가중치를 부여할 수 있습니다. 언제라도 가중치가 높은 서버에서 더 많은 요청을 받을 수 있습니다. 가상 서버의 관리자는 각각의 실제 서버에 가중치를 부여할 수 있습니다. 가중치의 비율인 실제 접속자수에 따라 네트웍 접속이 할당됩니다. 기본 가중치는 1입니다.

가중치가 있는 최소 접속 스케줄링 알고리즘은 최소 접속 스케쥴링 알고리즘에 비해 부가적인 배분작업이 필요합니다. 서버들이 같은 처리 용량을 가졌을때는 작업 할당의 간접비용을 최소화 하기위해 최소 접속 스케쥴링과 가중치가 있는 최소 접속 스케쥴링 알고리즘 둘 다 사용할 수 있습니다.

 


참고 : http://hakkoo.net/zeroboard/zboard.php?id=study&page=6&sn1=&divpage=1&category=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=desc&no=419&PHPSESSID=34ad0df0e6670171141d75494595ea57

 

리눅스 네트워크 명령어
- IP할당등은 부팅시 초기화됨. 영구적으로 변경하기 위하여, 아래 파일을 수정해야 함.

인터페이스(랜카드) 설정 정보 표시 : ifconfig
eth0 인터페이스(랜카드) 설정 정보 표시 : ifconfig eth0
IP 할당 : ifconfig eth0 192.168.1.1
여러 IP 할당 : ifconfig eth0:0 192.168.1.2
두번째 IP 할당 : ifconfig eth0:1 192.168.1.3
IP/Subnet 설정 : ifconfig eth0 192.168.1.1 netmask 255.255.255.0
eth0 인터페이스 disable : ifconfig eth0 down
eth0 인터페이스 enable : ifconfig eth0 up
접속여부, 응답시간, 패킷손실율 확인 : ping [웹주소 or IP]
현재 라우팅 테이블 보기 : route
기본 Gateway 설정 : route add default gw [gateway 주소]
IP 주소와 매칭되는 하드웨어 주소 표시: arp
IP 패킷이 목적지에 도달하기 위해 거치는 (라우팅) 경로추적 Trace Route: traceroute [web 주소]
IP 패킷이 목적지에 도달하기 위해 거치는 경로추적 Trace Path: tracepath [web 주소]
DNS Test : host [web 주소]
Advanced DNS Test : dig [web 주소]
Reverse Lookup : host 8.8.8.8
Advanced Reverse Lookup : dig -x 8.8.4.4

리눅스 네트워크 수정파일 (위와 동일한 기능. 영구저장)

// 네트워크와 호스트 명 설정
# vi /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=fedora.wiz.pe.kr

// 네트워크 인터페이스 설정
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
NM_CONTROLLED=yes
IPADDR=[IP주소]
NETMASK=255.255.255.0
GATEWAY=[Gateway 주소]
DNS1=168.126.63.1
TYPE=Ethernet
USERCTL=no
IPV6INIT=no

// 기본 DNS 설정
# vi /etc/resolv.conf
nameserver 168.126.63.1
// 네트워크서비스 자동 시작 해제
# chkconfig NetworkManager off
// 네트워크서비스 중지
# service NetworkManager stop
// 네트워크 자동 시작 등록
# chkconfig network on
// 네트워크 시작
# service network start

첨부:

Makefile - module programing Makefile 예시
ip_vs_rr.c - Round Robin 코드 (Linux kernel 원본에 존재)


sequence
1) ip_vs_rr.c를 적절히 수정.
2) Make 하여, Module 생성. (ip_vs_rr.ko)
3) 2)에서 생성한 파일을 /lib/module/(해당커널 버전)/kernel/net/netfilter/ipvs 로 복사
4) ipvs 실행 및 확인



팁 : 
1)  Line by Line
2) insmod : module 올림
    rmmod : mudule  내림
3) printk(""); 를 사용하여, 코드의 실행 부분 확인가능 - printk("") 는 dmesg 로 확인 가능
                   dmesg -c >> dmesg 출력 clear
    

/*

* Round-Robin Scheduling

*/

int i=1, n=1;

static struct ip_vs_dest *

ip_vs_rr_schedule(struct ip_vs_service *svc, const struct sk_buff *skb)

{

struct list_head *p, *q;

struct ip_vs_dest *dest;

IP_VS_DBG(6, "%s(): Scheduling...\n", __func__);

write_lock(&svc->sched_lock);

p = (struct list_head *)svc->sched_data;

if(i==n) // 이부분이 실행되면, 서버가 바뀜. 사용한 조건으로 인해, n번만큼 할당됨.

p = p->next;

q = p;

do {

/* skip list head */

if (q == &svc->destinations) {

q = q->next;

continue;

}

dest = list_entry(q, struct ip_vs_dest, n_list);

if (!(dest->flags & IP_VS_DEST_F_OVERLOAD) &&

atomic_read(&dest->weight) > 0)

/* HIT */

goto out;

q = q->next;

} while (q != p);

write_unlock(&svc->sched_lock);

IP_VS_ERR_RL("RR: no destination available\n");

return NULL;

out:

svc->sched_data = q;

write_unlock(&svc->sched_lock);

IP_VS_DBG_BUF(6, "RR: server %s:%u "

"activeconns %d refcnt %d weight %d\n",

IP_VS_DBG_ADDR(svc->af, &dest->addr), ntohs(dest->port),

atomic_read(&dest->activeconns),

atomic_read(&dest->refcnt), atomic_read(&dest->weight));

if(i==n){

n++;i=0;

}

i++;

return dest;

}

 

어느 프로그램이든지 만들려면 Makefile을 만들어야 합니다. 디바이스 드라이버도 역시 Makefile을 만들어 놓고 사용하면 편리합니다. 더욱이 커널 2.6에서는 gcc 를 이용하여 빌드하는 것이 아니기 때문에 반드시 Makefile을 만들어야 한다고 합니다.

저도 간단하게 프로그램을 작성해서 컴파일하려고 Makefile을 만들어 보았습니다.

Makefile 오류

MS-Windos에서 매우 편리한 RAPID 툴만 사용했던 저로서는 Makefile을 만들어야 한다는 것이 별로 반갑지 않습니다. 반갑지 않은 정도가 아니라 성가시고 때로는 알지 못하는 에러 때문에 고생해야 했습니다.

일반 에플리케이션을 만들기 위한 Makefile은 나름대로 큰 수정없이 사용할 수 있는 Makefile을 만들어서 사용할 정도가 되었습니다만 디바이스 드라이버를 학습하면서, 이것도 새로운 영역이라고 새로운 Makefile 형식에 사뭇 당황했습니다. 이것 또 암호문이네...으~

나름 빠르게 해본다고 책에 딸려 온 CD에 있는 소스 파일을 복사해서 main.c를 만들고 역시 CD에 있는 Makefile을 수정했습니다만 제대로 컴파일이 되질 않더군요. 가장 큰 잘못은 책에서 Makefile 부분을 대충 내용만 흝어 본 것이었습니다. 다시 책 내용을 정독하고 Makefile을 수정하고 컴파일해 보았지만 아래와 같은 에러가 계속 나더군요.

]$ make

make -C /lib/modules/2.6.9-42.0.8.ELsmp/build SUBDIRS=/home/jwjw/prjs/forum_sample/115 DeviceDriver modules

make[1]: Entering directory `/usr/src/kernels/2.6.9-42.0.8.EL-smp-i686'

make[1]: *** 타겟 `DeviceDriver'를 만들 규칙이 없음.  멈춤.

make[1]: Leaving directory `/usr/src/kernels/2.6.9-42.0.8.EL-smp-i686'

make: *** [default] 오류 2

]$ make

아~! 정말 미치겟더군요. 이런 기억이 예전에도 있었습니다. 바로  Tab 문자 때문이었죠.

그렇다면 이번에 발생한 에러는 무엇 때문일까요?

make[1]: *** 타겟 `DeviceDriver'를 만들 규칙이 없음. 멈춤.

문제는 바로 작업 디렉토리에 공백 문자가 있어서 였습니다. 공백만 없다면 한글 이름의 디렉토리 명을 사용해도 컴파일할 수가 있었습니다.

115_디바이스드라이버]$ make

make -C /lib/modules/2.6.9-42.0.8.ELsmp/build SUBDIRS=/home/jwjw/prjs/forum_sample/115_디바이스드라이버 modules

make[1]: Entering directory `/usr/src/kernels/2.6.9-42.0.8.EL-smp-i686'

  CC [M]  /home/jwjw/prjs/forum_sample/115_디바이스드라이버/main.o

  Building modules, stage 2.

  MODPOST

  CC      /home/jwjw/prjs/forum_sample/115_디바이스드라이버/main.mod.o

  LD [M]  /home/jwjw/prjs/forum_sample/115_디바이스드라이버/main.ko

make[1]: Leaving directory `/usr/src/kernels/2.6.9-42.0.8.EL-smp-i686'

115_디바이스드라이버]$

다른 프로그램 컴파일에서는 현재 디렉토리 정보가 중요하지 않았습니다만 디바이스 드라이버, 즉 모듈 프로그래밍에서는 현재의 디렉토리 명을 Makefile에 넘겨 주어야 하므로 Makefile 이 헤깔리지 않도록 디렉토리 명에 공백 문자가 있어서는 안되겠습니다.

또한 커널 별로 컴파일하는 방법이 다릅니다. 다음에 소개되는 커널별 Makefile을 참고하시기 바라며, 혹 사용하시는 시스템의 커널 버전을 확인하시려면 uname -r 을 이용하십시오.

]$ uname -r

2.6.9-42.0.8.ELsmp

]$

Makefile에 대해서는 리 눅스 디바이스 드라이버, 저자 유영창의 책 내용 중 4장 4절의 내용을 그대로 사용하면서 읽기 편하게 편집했습니다. 원저자에 누를 끼치지 않기 설명 글은 원문 그대로 가져 오지 않고 요점만 간추렸음을 말씀드립니다.

2.4 커널 외부 모듈 컴파일 용 Makefile

우선 Makefile의 전체 모습을 보시겠습니다. 예에서는 소스 파일 이름이 test.c 라고 가정하겠습니다.

KERNELDIR   = /lib/modules/$(shell uname -r)/build

CFLAGS      = -D__KERNEL__ -DMODULE -I$(KERNELDIR)/include -O



all: test.o



clean:

   rm -rf *.o

Makefile	설  명
KERNELDIR = /lib/modules/...	모듈은 커널과 밀접하게 연관되어 있으므로 버전 문제를 방지하기 위해서는 모듈이 동작하는 커널 소스와 일치시켜야 하는데, 이를 위해 컴파일할 모듈이 참조할 커널 소스의 디렉토리를 지정한다.
CFLAGS = -D__KERNEL__ ...	D__KERNEL__ : 커널과 관련된 내용을 활성화 하라 DMODULE : 모듈과 관련된 내용을 활성화 하라 O : 최적화 옵션
test.o	만들어낼 오브젝트
clean:     rm -rf $*.o	컴파일 결과로 생긴 모든 파일을 삭제

test.o 가 하나의 소스가 아니라 여러 개의 소스 파일로 만들어 진다면 아래와 같이 내용을 추가하시면 됩니다.

all: test.o



test.o : test1.o test2.o test3.o

2.6 커널 외부 모듈 컴파일 용 Makefile

2.6 커널 용은 2.4보다 조금 복잡해 보이는 듯 합니다. 프로그램 소스가 어디에 있는지도 보여 주어야 하고 말이죠. 그러다 보니 위에서 말씀드린 Makefile 오류 경험도 했습니다만 내용을 보면 모듈을 만들어 내기 위해서 2.4보다는 더욱 전문적이고 체계적으로 보입니다.

KERNELDIR = /lib/modules/$(shell uname -r)/build



obj-m   := test.o



KDIR    := /lib/modules/$(shell	uname -r)/build

PWD     := $(shell pwd)



default:

   $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules



clean:

   rm  -rf *.ko

   rm  -rf *.mod.*

   rm  -rf .*.cmd

   rm  -rf *.o

Makefile	설  명
KERNELDIR = /lib/modules/...	모듈은 커널과 밀접하게 연관되어 있으므로 버전 문제를 방지하기 위해서는 모듈이 동작하는 커널 소스와 일치시켜야 하는데, 이를 위해 컴파일할 모듈이 참조할 커널 소스의 디렉토리를 지정한다.
obj-m := test.o	생성할 모듈 이름
KDIR := /lib/modules/$(shel ...	커널의 소스 위치
PWD := $(shell pwd)	컴파일 대상 프로그램 소스 위치
default:    $(MAKE) -C $(KDIR) ...	모듈 컴파일 명령
clean:    rm -rf *.ko .....	컴파일 결과로 생긴 모든 파일을 삭제

test.o 가 하나의 소스 파일로 되어 있지 않고 여러 파일로 만들어져 잇다면 아래와 같이 행을 추가하시면 됩니다.

obj-m	:= test.o

module-objs := test1.o test2.o test3.o

이제 컴파일해서 모듈을 만들어 내는 방법까지 알게 되었으므로 다음 시간부터는 디바이스 드라이버 프로그램에 작성에 대해 하나씩 알아 보도록 하겠습니다.

 

태그: *디바이스드라이버

참조: http://forum.falinux.com/zbxe/?document_srl=406210&mid=device_driver

 http://www.linuxvirtualserver.org/
사이트를 접속해서 ipvsadm-1.25.tar.gz 을 받습니다.

압축을 풀어 줍니다.

압춘 폴더에 들어가 make를 실행시켜주면

[root@namyong ipvsadm-1.25]# make install
make -C libipvs
make[1]: Entering directory `/home/namyong/바탕화면/ipvsadm-1.25/libipvs'
gcc -Wall -Wunused -Wstrict-prototypes -g -fPIC -DLIBIPVS_USE_NL  -DHAVE_NET_IP_VS_H -c -o libipvs.o libipvs.c
In file included from libipvs.h:13,
                 from libipvs.c:23:
ip_vs.h:15:29: error: netlink/netlink.h: 그런 파일이나 디렉터리가 없습니다
ip_vs.h:16:31: error: netlink/genl/genl.h: 그런 파일이나 디렉터리가 없습니다
ip_vs.h:17:31: error: netlink/genl/ctrl.h: 그런 파일이나 디렉터리가 없습니다
In file included from libipvs.h:13,
                 from libipvs.c:23:
같은 에러가 발생합니다.

위 에러를 해결하기 위해서는 http://www.infradead.org/~tgr/libnl/에
들어가서 libnl-2.0.tar.gz 파일을 다운로드 하여 압축을 풀어줍니다.

libnl은 netlink socket를 다루는 프로그램을 위한 라이브러리입니다.

압축이 풀린 폴더를 들어가보면 inclued/netlink/version.h.in이라는 파일이 있습니다.
그 파일의 이름을 version.h로 변경해줍니다.
그리고 include폴더를 통째로
/usr/include에 덮어쓰기를 합니다.

덮어쓸때 에러가 발생한다면 chmod 명령어를 이용해 잠깐 권한을 풀어준 후 다시 시도하면 됩니다.

덮어쓰기가 끝나면

make clean을 한후
make를 실행시키면 됩니다.

혹시 make 실행 도중 popt.h 파일 등등 기타 파일을 찾을수 없다고 나오면
chmod - R 777 /usr/include와 같이 권한을 잠시 풀어주고 다시 시도하면 해결할 수 있습니다.

목적 : 플래시 메모리는 어디서 어떻게 초기화되고 작동이 되는지 알아보자.

필자가 사용하는 망고보드의 부트로더는 U-boot이다. U-boot안에 있는 Startup.S파일이 가장 먼저 실행이 되는데 Startup.S의 메모리 컨트롤러 초기화 부분이 있다. 바로 이부분부터 접근해보도록 하자.

NAND 작업 진행 상황(1) 까지의 내용을 계속하여 진행.


가정 : mango-2010-6 버전에 s5pc100의 nand driver가 존재 할 것이다.

근거 : mango-2010-6/cpu/s5pc1xx/nand.c 파일 존재.



진행 : mango-2010-6/cpu/s5pc1xx/nand.c   ->  U-Boot-2010.6.29   이식

결과 : NAND 드라이버 인식 .




진행과정 :
NAND 작업 진행 상황(1) 에서