yocto hob와 비트베이크 툴에 대해 알아볼까요?

Hob은 비트베이크의 사용자 친화적인 인터페이스

Hob은 이미지를 변경하고 사용자가 원하는 방법의 이미지를 이용할 수 있도록 도움을 준다.

또한 hob은 이미지를 만든 후 qemu에서 이미지를 바로 실행시킬 수 있게 한다.

 

Hob을 사용한 이미지 빌드

yang@yang:~$ source poky/oe-init-build-env [build-directory]
 

yang@yang:~$ hob
 

Hob은 로컬 환경설정과 이용 가능한 메타데이터 레이어를 읽어 여러 파싱 작업들을 수행한다. 이 작없이 끝난 후, hob은 이용 가능한 머신의 목록을 보여준다.

 

Hob을 사용한 이미지 편집

레세피를 선택하고 해제함으로써 추가 삭제할 수 있다.

 

비트베이크는 필요한 추가 패키지를 포함하여 선택된 패키지들의 모든 의존성을 분석한다.

Build image버튼을 클릭하고 기다리면 자동으로 이미지가 나오게 된다.

 

Hob은 기존에 있는 이미지에서 이미지를 수정하고 일부 패키지를 추가할 수 있는 좋은 툴이다. Hob은 작업슬 쉽게 할 수 잇는 훌륭한 사용자 친화적 인터페이스이고 팀 작업을 하는데 있어서 이미지를 임시로 수정하는 데 유용하다.

비트베이크 툴

욕토 프로젝트와 오픈 임베디드 프로젝트는 비트베이크를 사용하는 가장 잘 알려진 프로젝트이자 가장 활발한 그룹이다. 비트베이크는 portage로부터 분리되어 독립적인 개발 주기와 메일링 리스트를 가지고 있다. 비트베이크는 여러 측면에서 gnu make 툴과 비슷하게 이해될 수 있다.

 

메타데이터

비트베이크가 이용하는 메타데이터는 다음 세종류로 분류된다.

    환경설정

    클래스

    레시피

환경 설정 파일들은 전역 변수들을 정의하는 데 이를 이용해서 레시피에 정보를 전달하고 레시피가 어떻게 동작할지 결정한다. 클래스는 전체 시스템에서 사용되고 레시피들이 필요에 따라상속할 수 있다. 기본값으로 사용될 수도 있는데 이 경우에는 시스템 전체의 행동의 정의하고 기본 함수를 제공하기 위해 사용된다. 클래스와 레시피는 실행될 태스크를 설명하고 비트베이크가 태스크 체인을 만드는 데 필요한 정보를 제공한다. 레시피가 하나 이상의 클래스를 상속받을 수 있게 하여 코드 중복을 줄이고 유지보수를 쉽게 만든다.

 

메타데이터 파싱

비트베이크가 가장 먼저 파싱하는 메타데이터는 .conf로 구분되는 환경 설정 파일이다. 이 메타데이터는 전역으로 적용되고 따라서 실행될 모든 레시피와 태스크에 영향을 미친다.

 

의존성

레시피들은 빌드 시에 필요한 패키지를 선언해야 한다. 비트베이크는 빌드 시점 의존성이 지켜지는지 빌드를 시작하기 전 체크한다.

    의존성이 없는 레시피들은 병렬로 빌드된다.

    의존성이 있는 레시피들은 의존성을 만족시키는 방향으로 순차적으로 빌드된다.

 

레시피 프로바이더와 프레퍼런스

레시피들 간의 의존성은 비트베이크와 빌드 툴의 핵심이다. 이는 레시피 안에서 변수로 정의되는데 레시피가 의존하는 것은 depends로 레시피가 프로바이드 하는 것은 provides로 정의된다.

    Bar_>version>.bb 형태로 레시피 자체가 bar를 프로바이드 한다.

    provides 변수에 bar가 할당된 레시피가 bar를 프로바이드 한다.

Virtual/kernel 프로바이더는 머신에 따라 커널이 달라지기 때문에 일반적으로 머신 정의 파일에서 설정된다. 같은 시스템에서는 두개의 다른 레시피가 하나의 의존성을 위해 다른 프로바이더를 사용할 수 없다.

소스코드 다운로드

비트베이크가 지원하는 주요 기능 중 하나는 소스 코드를 다운로드하는 것이다. 이 기능은 최대한 모듈화되고 유연하게 설계 되었다. 비트베이크가 소스코드를 다운로드하는 메커니즘은 내부적으로 페처 백앤드라고 부른다. 사용자의 요구사항과 소스코드를 다운로드를 최적화하기 위한 여러 가지의 페처 백엔드가 존재한다. 비트베이크는 깃, supervision, bazaar, osc, http, https, ftp, dvs, mercurial, perforce, ssh와 같이 다양한 페처 모듈을 지원한다.

 

원격파일 다운로드

비트베잌는 원격 파일 다운로드를 위해 몇가지 방법을 지원한다. http, https, ftp이다. 다음 빌드에서 같은 파일을 필요로 할 떄 이미 파일이 다운로드가 되어 있는 것을 확인하고 재사용 할 수 있다. 이 과정은 비트베이크가 다운로드하는 모든 원격 소스 파일에 적용된다.

 

깃 저장소

가장 널리 이용되는 소스코드 관리 시스템은 깃이다. 비트베이크는 깃도 지원하며 깃 백앤드는 do_fetch 태스크가 실행될때 src_Uri에서 git://으로 시작되는 url을 찾았을 때 실행된다.

 

다른 저장소

원격 파일과 깃 저장ㅅ오는 비트베이크 페처 백앤드 중 가장 흔하게 사용되는 방식이다. 다른 소스코드 관리 방식은 구현 방식은 다르지만 큰 개념은 동일한 방식으로 이루어진다.

 

소스코드 다운로드 최적화

소스코드 다운로드의 안정성을 강화하기 위해 포키는 다음 설정을 할 수 잇는 미러 메커니즘을 제공한다.

    1순위로 접근하는 다운로드 서버 제공

    1순위가 실패했을 때 접근하는 서버 제공

네트워크 접근 제한

정책 : 회사에서 법적 검토없이 외부 소스코드가 전체 제품에 포함되는 것을 금지할 수 있따. 

통신비 : 모바일 통신을 사요하고 있을 떄 다운로드할 데이터들의 용량이 크면 통신비가 부담이 될 수 있다.

빌드 속도 : 이미 소스코드를 다운로드 받아 놓는 경우 네트워크를 꺼서 빌드 속도를 증가시킬 수 있다.

네트워크 사용 불가 : 대떄로 네트워클를 이용하지 못하는 상황에 놓일 수 있다.

비트베이크 태스크

$: bitbake <recipe>

$: bitbake <recipe> -c <task>

특정한 태스크만 실행하고 싶다면

$: bitbake <recipe>

정의된 태스크를 알아보기 위해서는

$: bitbake <recipe> -c listtasks

태스크 확장

태스크의 내용이 요구사항을 만족시키지 못할 때에는 내용을 원하는 것으로 교체하거나 덧붙일 수 있다. _append와 _prepend 명령어가 태스크를 확장할 때 사용된다.

루트 파일 시스템 이미지 생성

포키의 가장 일반적인 사용 방식 중 하나는 루트 파일 시스템 이미지 생성이다. 루트 파일시스템 이미지는 실제 타깃에서 바로 이용 가능한 형태여야 한다. 이미지는 하나의 파일 시스템으로 만들어지거나, 리눅스 커널, 디바이스 트리, 부트로더, 또 다른 파일 시스템 처럼 다른 아티팩트를 포함할 수 있다. 이미지를 만드는 과정은 몇 가지 단계를 포함하고 일반적인 사용법은 다음과 같다.

1. Rootfs 폴더 생성

2. 필요한 파일 생성

3. 최종 파일시스템을 특정한 요구사항에 따라 감싸기

4. 가능한 상태라면 압축