시크한 공돌이의 IT 블로그

1. 목적

ㄱ. 우분투 상의 블루투스 디바이스의 이름을 변경하여 보자

2. 본론

ㄱ. 우분투의 블루투스 디바이스의 이름을 바꾸기 위해 블루투스 기기의 adress를 먼저 확인

ㄴ. 확인하여 나오는 블루투스의 adress가 XX:XX:XX:XX:XX:XX라 가정하고 다음의 파일을 편집하면 블루투스 기기의 이름을 변경할 수 있다.

ㄷ. 그 후 다음 명령어를 실행하여 블루투스를 재시작 해줌

3. 결론

ㄱ. 블루투스 디바이스의 이름 변경을 하는 법을 알아보았음.

1. 목적

ㄱ. 리눅스 ./configure시에 다음의 에러가 발생할 때 어떻게 해결하는지 알아본다.

2. 본론 

ㄱ. 위의 에러의 마지막을 보면 새로 만들어진 파일이 분산된 파일들보다 오래되었다 라는 말이 있고 시스템 시간을 확인하라고 한다.

ㄴ. 이는 리눅스 시스템의 시간 이상으로 인한 에러임으로 rdate나 ntp같은 시간 관리 소프트웨어를 통해 정상적인 시간을 맞춰주게 되면 해결된다.

ㄷ. 아래와 같이 수동으로 변경도 가능하다.

3. 결론

ㄱ. ./configure의 에러를 해결하는 법을 알아보았다.

1. 목적

ㄱ. 리눅스 시작시에 NFS 디렉토리를 자동으로 마운트 해보자

2. 본론

ㄱ. 리눅스의 NFS 디렉토리를 시작시에 자동으로 마운트 하기위해 데몬 서비스로 등록해야함

a. 데몬은 리눅스 서버가 부팅할 때 백그라운드 프로세스로 실행되고 있는 프로그램이다.

i. 리눅스는 다양한 기능과 서비스를 제공하기 위해 많은 데몬 프로세스를 실행

ii. 대부분의 데몬 프로세스는 마지막에 d라는 문자를 포함

iii. 리눅스에서는 네트워크 관련 서비스 처리를 데몬이 담당

iv. 데몬은 독립형 데몬과 수퍼데몬으로 구분

ⓐ. 독립형 데몬

- 웹 서버(HTTPD), DB 서버(MYSQLD)와 같잉 시스템에 독자적으로 프로세스가 구동되어 서비스를 제공

- 항상 메모리에 상주하고 대기하여 클라이언트 요청을 기다림

' 자주 호출되는 서비스의 경우 메모리에 상주시켜 독립형 데몬으로 사용하는 것이 적절

- 독립형 데몬의 실행 스크립트 파일은 대부분 /etc/init.d/ 디렉토리에 존재

- 독립형 데몬의 실행 형식

ⓑ. 수퍼 데몬

- 작은 규모의 서비스는 종속형 데몬으로 필요 시에만 수퍼 데몬이 작동시킴

- 평소에는 4개의 데몬 프로세스가 잠자고 있지만, 타겟 시스템이 호스트 시스템에 서비스를 요청하면 수퍼 데몬을 통하여 서비스 제공

- 수퍼 데몬 XINETD는 /etc/xinetd.d/<데몬 프로그램 이름> 이라는 다수의 설정 파일 사용

' 종속형 데몬 관련 설정 파일을 수정하면 수퍼 데몬을 반드시 재실행

' 요청이 종료되면 서비스 데몬도 종료

b. 부팅 시 자동으로 서비스를 실행

i. 부팅 시 자동으로 서비스를 실행하는 절차

ⓐ.  /etc/init.d에 실행 서비스 셀 프로그램 작성

ⓑ. update-rc.d 명령으로 작성된 스크립트를 초기화 스크립트 링크에 등록

-> target.sh의 서비스를 부팅 시 마지막 순서(99)로 실행하도록 등록

ii. 타겟 시스템에서 부팅 시 자동으로 네트워크 IP 설정하고, 호스트의 NFS 공유 디렉토리를 마운트 하는 서비스 등록

ⓐ. /etc/init.d/target.sh 셀 스크립트 작성

ⓑ. update-rc.d 실행하여 등록

ⓒ. 재 부팅 후 확인

c. 자동 실행되는 셀 파일 생성하고, 실행권한 부여 후 등록

d. 기존 연결했던 NFS 마운트 해제 후 재 부팅 해봄

e. 재 부팅 후 마운트 된 것을 알 수 있음.

3. 결론

ㄱ. 리눅스 데몬 등록을 통해 NFS 디렉토리를 자동으로 마운트 해보았다.

1. 목적

ㄱ. apt-get update 시에 fetch to fail 에러가 발생 할 때가 있다.

2. 본론

ㄱ. 보통 다음에 동작에 해결할 수 있다.

ㄴ. 위의 동작으로 해결이 안되는 경우 아래와 같이 해결한다.

ㄷ. 위의 명령어 후에 apt-get update를 하면 해결되게 된다.

3. 결과

ㄱ. apt-get update의 fail to fetch 에러시 해결 방법을 알아본다.

1. 목적

ㄱ. BlueZ의 simplescan 예제를 테스트 한다.

ㄴ. gcc를 통해 blueZ를 포함하여 컴파일 하는 법을 배워본다.

2. 본론

ㄱ. mit 대학의 bluetooth 관련 강의의blueZ 예제를 참고한다.

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/socket.h> #include <bluetooth/bluetooth.h> #include <bluetooth/hci.h> #include <bluetooth/hci_lib.h> int main(int argc, char **argv) { inquiry_info *ii = NULL; int max_rsp, num_rsp; int dev_id, sock, len, flags; int i; char addr[19] = { 0 }; char name[248] = { 0 }; dev_id = hci_get_route(NULL); sock = hci_open_dev( dev_id ); if (dev_id < 0 || sock < 0) { perror("opening socket"); exit(1); } len = 8; max_rsp = 255; flags = IREQ_CACHE_FLUSH; ii = (inquiry_info*)malloc(max_rsp * sizeof(inquiry_info)); num_rsp = hci_inquiry(dev_id, len, max_rsp, NULL, &ii, flags); if( num_rsp < 0 ) perror("hci_inquiry"); for (i = 0; i < num_rsp; i++) { ba2str(&(ii+i)->bdaddr, addr); memset(name, 0, sizeof(name)); if (hci_read_remote_name(sock, &(ii+i)->bdaddr, sizeof(name), name, 0) < 0) strcpy(name, "[unknown]"); printf("%s %s\n", addr, name); } free( ii ); close( sock ); return 0; }

ㄴ. ㄱ의 소스는 simplescan.c의 소스이다. 컴파일은 다음의 명령어를 통해 하게 된다.

ㄷ.  컴파일 후 생성되는 scantest 파일일 실행하게 되면 다음과 같은 결과를 볼 수 있다.

3. 결론

ㄱ. BlueZ를 통한 simplescan.c 예제를 실습해보았다.

ㄴ. 블루투스 기기들이 검색되는 것을 볼 수 있다.

1. 목적

ㄱ. 리눅스 베이스에서 블루투스 통신 프로그래밍을 해보자.

ㄴ. 기반을 준비해 보자

2. 준비

ㄱ. BlueZ 라이브러리 소개

리눅스 상에서 블루투스 장비를 프로그래밍 하기위해서는 보통 BlueZ 라이브러리를 이용합니다. (씨리얼 방식으로 통신하기도 하는 듯합니다.)

BlueZ 라이브러리는 리눅스 환경에서 Bluetooth 무선 표준 스펙을 구현한 구현물입니다. 공식적으로 이 프로젝트는 Kernel 2.4, 2.6 을 지원합니다.

http://www.bluez.org/

ㄴ.  BlueZ 라이브러리 설치 및 설정

리눅스 상에서 BlueZ 를 동작하도록 하기 위해서는 우선 라이브러리를 설치해야합니다. 

http://www.bluez.org/download.html

a. 아래 명령어를 통해 BlueZ 라이브러리를 받음

b. 우분투에서 상기 명령어들을 실행하면 ### ERROR: configure: error: GLib >= 2.28 is required 발생 

이유 : glib가 설치 되어 있지 않기 때문에 -> 아래 명령어로 glib 설치

c. 위 명령어 후 다시 실행하면 ### ERROR: configure: error: D-Bus >= 1.4 is required 발생

d. 또 실행하면 ### ERROR: configure: error: USB library support is required 발생

e. 다시 실행하면 ### ERROR: configure: error: libudev >= 143 is required 에러 발생

f. 실행하면 ### ERROR: configure: error: libical is required 발생

e. ### ERROR: /usr/bin/ld: cannot find -lreadline 나 reading headline 에러가 발생하면 

f.   위설정들 설치 후에 다시 아래 명령어들 수행

상기의 페이지에서 BlueZ 라이브러리의 최신버전을 받으시고, 컴파일한뒤 구동 환경으로 복사하시기 바랍니다.

이때, BlueZ 라이브러리를 구동하는 환경이 커널 2.4 시리즈인 경우 커널상에 Bluetooth 스택이 올라가있지 않은 경우가 있습니다. 이 경우 패치 커널에 적용하고 다시 설치해야만 정상적으로 블루투스를 이용할 수 있습니다. 

각 커널 별 블루투스 스택 지원 사항에 대한 설명과 패치 파일 및 패치 과정에 관련된 설명은 아래 사이트를 참고하시기 바랍니다.

http://www.holtmann.org/linux/kernel/

일단 커널 스택과 라이브러리가 정상적으로 설치되었다면 블루투스 동글을 삽입한뒤 다음과 명령어를 통해서 삽입된 블루투스 장비가 있다는 사실을 확인하시기 바랍니다. (제 경우에는 USB 형태의 동글을 이용했습니다.)

만약, 리눅스 커널이 삽입된 동글을 인식했다면 hci0 라는 디바이스가 잡힐 것 입니다.

명령어를 이용해서 해당 디바이스를 활성화시키시면 모든 준비작업이 끝납니다.

1. 목적

ㄱ. cpufreq.h 파일을 분석하여 DVFS 관련 정책 함수를 찾아냄

2. 내용

ㄱ. 리눅스 커널 소스 안에 arch/arm/mach-exynos/cpufreq.h 분석

cpufreq_policy_notifier_call  함수가 정책을 변경하는것으로 보임

 *policy에 data를 넣고 코드에 따라서 바뀌는 것으로 보임

int exynos_cpufreq_lock(unsigned int nId, enum cpufreq_level_index cpufreq_level)

1. 목적

ㄱ. 오드로이드의 주 프로세서인 a9의 PMU driver가 동작하는 알아본다.

2. 내용 

ㄱ. 콘솔에 'dmesg | grep PMU'을 입력하면 관련 메세지가 출력됨

그림 1과 같이 7개의 카운터를 지원한다고 함

그림 1. PMU관련 메세지

3. 결론

ㄱ. PMU 드라이버의 동작을 확인하였고 7개의 카운터가 사용 가능함을 볼 수 있었음.

1. 목적

ㄱ. 리눅스에서 성능 모니터링 권한 관련 부분을 분석해 본다.

ㄴ. 권한 분석 후 SW와 HW 모니터링을 카운터 해본다.

2. 내용

ㄱ. 리눅스에서 커널 모니터링 권한

/proc/sys/kernel/perf_event_paranoid <- 모니터링 권한을 가지고 있음

proc은 램디크크 이므로 시동시 초기화됨(커널 수정을 통한 값 변경이나 모듈 실행시 변환 요함)

cat으로 열어보면 권한 표시 / 권한은 아래와 같음

그림 1. paranoid 확인과 설정

확인 후 카운터 샘플 돌려본 결과

그림 2와 같이 SW는 여전히 카운팅 되지만 HW는 안됨

그림 2. SW, HW 카운트 샘플

참조  : http://wrightsolutions.wordpress.com/category/virtualisation/virtualbox/

http://unix.stackexchange.com/questions/14227/do-i-need-root-admin-permissions-to-run-userspace-perf-tool-perf-events-ar

3. 결론

ㄱ. 권한을 담당하는 램디스크 상주 파일을 분석하여 이벤트 모니터링에 대한 권한을 설정하여 보았다.

ㄴ. 권한을 proc 상에서 변경하여 카운팅 해본 결과 SW 성능 이벤트는 카운팅 되었지만 HW 성능 이벤트는 카운팅 하지 못하였다.

1. 목적 

ㄱ. odroid x2 타깃으로 DVFS 및 performance monitering을 하기위해 cpufreq.h, perf_event.h를 분석한다. 

2. 내용 

ㄱ. 먼저  리눅스 커널/include/linux/perf_event.h의 분석

파일 중간에 sample관련 함수부가 나옴 참조 (1012 줄)

그림 1. perf_event.h속의 perf_output_sample 및 관련 함수부

 그림1을 참고하면 흔히 커널 모듈 프로그램에서 볼 수 있는 값 반환 형식이 아닌 struct 포인터로 값을 지정하고 주고 받는것으로 보임

perf_output_handle의 stuct는 아래와 그림 2와 같음.

그림 2. perf_output_handle의 strucure

 그림 2 하단을 보면 perf_output_handle의 구조가 보이는데 이중 event와 buffer, void 형 포인터인 addr을 주목해야 할 것으로 보임.

(perf_buffer 구조형 *buffer와 void형 *addr 중 하나가 데이터를 받을 것으로 추정 - 후에 코멘트 업데이트 예정)