yocto 프로젝트 디버깅과 외부 레이어에 대해 알아볼까요?

메타데이터와 애플리케이션 디버깅

메타데이터 디버깅은 비트베이크의 작업이 목표에 맞도록 보장을하고, 문제를 일으킨 부분에 대해 식별하기 위해 필요로 한다. 작업의 실행 경로를 추적하는 것에 대한 도움을 주기 위해 호스트에서 비트베이크에 의해 생성되는 여러 로그 파일을 사용한다. 반면 런타임 시 디버깅은 애플리케이션, 라이브러리 또는 커널의 정상적인 개발 주기 동안 디버깅을 하는 것과 같아 좀 더 익숙하다.

 

이미지, 패키지, SDK 콘텐츠 추적

예상되는 콘텐츠와 이미지, 패키지, SDK를 제대로 가지고 있는지 확인하는 가장 쉬운 방법은 빌드 히스토리 메커니즘을 사용하는 것이다. 이 콘텐츠는 레시피가 변화될 때 예상되지 않은 방법들에 의해 변화가 된다. 모든 패키지, 이미지, SDK들의 빌드된 데이터는 이 데이터를 사용하여 추가 정보를 쉽게 추출하기 위해 build/buildhistory 디렉토리 내에 텍스트 파일로 저장이 된다. 포키는 두 개의 buildhistory 상태의 다른 점을 보기 위해 더 간결한 방식의 buildhistory-diff라 불리는 유틸리티를 제공한다.

strace 패키지가 coore-image-minimal 이미지에 추가되었을 때 buildhistory-diff에 의해 강조되면서 다른 점을 보여준다.

 

작업 실행 기간의 로그 정보

비트베이크에서 제공하는 로깅 유틸리티들은 코드 실행 경로를 추적하는 데 매우 유용하다. 비트베이크는 다음과 같이 파이썬과 셸 스크립트 코드를 사용하여 로깅 기능을 제공한다. 

파이썬 : 파이썬 함수를 사용하기 위해 비트베이크는 여러 로그 레벨을 지원한다.

셸 스크립트 : 셸 스크립트 함수에서 사용하기 위해 파이썬의 로그레벨과 같은 집합이 존재하며 비슷한 문법을 사용할 수 있다.

 

개발 셸 이용

패키지를 수정하거나 빌드 실패를 디버깅할 때, 개발 셸은 유용한 툴이 될 수 있다. devshell을 사용할 때 소스 파일은 작업 폴더에 압축이 풀리고 패치가 적용되며 새로운 터미널이 열리게 된다.

$: bitbake linux-yocto -c devshell

devshell을 사용하면 리눅스 커널 소스 코드를 다시 작업하고 빌드할 수 있고, 개발머신에서 처음부터 다시 빌드를 하지 않을 수 있고, 필요에 따라 소스 코드를 바꿀 수 있다.

 

디버깅을 위해 GNU 프로젝트 디버거 사용

가끔 메모리 또는 디스크 사용량 제약 때문에 타깃에서 직접 디버깅을 하기 위한 GDB를 사용할 수 없다. 이 제약은 gdb가 디버깅 정보와 비록 디버깅 시작 전이지만 디버깅이 될 프로세스의 바이너리들을 로드하고 함수 이름, 변수, 이름과 값, 스택 추적 등을 수행하는데 필요한 것들을 로드하는 것이 필요해서 발생된다. 호스트 GDB가 디버깅 정보를 로드하고 디버깅에 필요한 처리를 수행하는 책임을 가짐으로써 타깃에서 디버깅 심볼을 설치할 필요가 없고, 호스트는 디버깅 정보를 가진 바이너리를 접근할 수 있으면 된다. 그것은 타깃 바이너리가 디버깅을 가능하게 하기 위해 최적화 없이 컴파일 될 때 가능하게 된다.

포키의 가장 유용한 기능 중 하나는 외부 레이어를 사용할 수 있는 유연성이다.

 

레이어를 이용한 유연성 확보

포키는 머신 설정 파일들, 클래스들, 간단한 애플리케이션부터 화면을 구성하는 스택들과 프레임워크까지 방대한 양의 메타데이터를 포함한다. 레이어를 이용하는 가장 큰 이유는 방대한 양의 프로바이더들을 구조화하고 사용자가 원하는 프로바이더만 선택할 수 있게 하기 위해서다. 또한 이 방법으로 다른 아키텍처에서 사용될 수 있거나 사용자가 원하는대로 수정된 소스코드를 제공할 수 있다. 각 프로젝트에서 필요한 레이어들을 선택할 수 있다. 또한 제공된 소스코드를 구미에 맞게 수정해서 패키지가 제품에서 동작하는 방식이나 패키지가 아키텍처에 맞게 빌드되게 할 수 있다. 커스텀 프로젝트 환경을 만들 떄 하나의 레이어에 모든 변경을 적용하면 안되고 서로 다른 레이어에 작업해야 한다.

$: bitbkae-layers show-layers

포키는 3개의 각기 다른 레이어로 구조화되어있고, 세개의 타입이 가능하다. Meta 레이어는 오픈임베디드 코어, 메타데이터이고 레시피, 클래스, qemu 머신 환경설정 파일을 포함한다. 이 레이어는 소프트웨어 레이어다. 소프트웨어 레이어는 어떤 아키텍처에서도 이용될 수 있는 애플리케이션과 이를 위한 환경설정 파일들을 포함한다. 지속가능하고 가장 적합한 방법은 디스트리뷰션과 디스트리뷰션 레이어를 생성하고 distro 파일을 이 안에 넣는 것이다.

 

레이어의 소스코드에 대한 고찰

 

보통 레이어들은 위 그림과 같은 폴더 구조를 갖고 있다.

 

Bsp 레이어의 conf 폴더는 다음 그림과 같이 나타나야 한다.

 

디스트리뷰션 레이어라면 폴더는 다음 그림과 같아야한다.

 

 

메타레이어 추가

욕토 프로젝트, 오픈임베디드, 커뮤니티들, 벤더들에서 제공되는 수백개의 메타레이어들이 존재하고 개발할 때 필요한 부분은 프로젝트 소스 폴더 안에서 수동으로 받아와야 한다. Meta-realtime을 프로젝트에 추가하고 싶다면 레이어 환경 설정 파일의 내용을 바꾸면된다. 그림과 같이 hob를 사용한다면 add layer를 클릭하고 meta-realtime 폴더를 찾은후 ok를 클릭한다.

비트베이크 명령어 라인을 사용한다면 다음 소스코드와 같이 conf/bblayer.conf 파일을 바꾸고 새 메타 레이어의 절대 경로를 추가함으로써 새 레이어를 추가할 수 있다. 음영 처리된 라인이 추가된 코드이다. 다른 것들은 디폴트 값들이다.

이 이후에 추가된 레이어가 파싱되고 meta-realtime 메타데이타는 비트베이크의 데이타베이스에 포함되어 레이어 안에 있는 레시피들이 사용될 수 있게 한다.