Yocto Project 소개

Yocto Project 소개(배경)

 

Embedded Linux 개발환경에서 제일 문제가 되었던 것은 Target(Chipset)에 대한 의존성이다.

예를들어 Android 같은 경우 한번 소스를 받으면, 그 안에 모든 Package가 다 들어있지만, Embedded Linux 환경으로 넘어오게 되면 정형화된 Package/Structure가 없기 때문에 환경 구성을 해야하지만 파편화 되어 흩어져 있다.

따라서 Yocto Project는 빌드환경, 유틸리티, 툴체인을 자체적으로 만들기 때문에, 사용자 작업환경과의 의존성이 줄어들어 호스트 환경에 따른 차이가 발생할 여지가 적다.

---

Bitbake(make)

- Gentoo Linux의 패키지 관리 시스템인 Portage에서 분리되어 나온 프로젝트로서, Poky의 작업 스케쥴러.

- Python 과 shell script로 구성된 metadata를 기반으로 parsing 하여 task를 생성하고, task를 실행한다.

 

OpenEmbedded-Core

- Poky build tool의 핵심이고, 주요 기능을 제공함

- 5개의 다른 프로세스 아키텍처(ARM, x86, x86-64, PowerPC, MIPS, MIPS64)를 지원하며, QEMU emulator를 지원한다.

 

Metadata

- Recipes(.bb and .bbappend) : sw의 특정 부분에 대한 세부 정보 제공

- Class(.bbclass) : 여러 recipe들이 공통으로 사용하는 기본 기능을 제공

- Configuration(.conf) : Poky가 어떻게 동작할지 결정하는데 사용하는 전역 변수들을 정의

 

Layer

Recipes들을 어떠한 목적에 의해서 Grouping 시킨것 이라고 볼 수 있다.

 

Bitbake와 OpenEmbedded-Core가 짝이 이루어지고, Metadata를 구축을 한면 폭팔적인 build system이 구축이 된다.

하지만 구축을 위해선, 위에서 언급된 3가지들 설정을 해야 하는데 설정하는 방법이 쉽지는 않다. 그러한 설정을 편하게 해주는 것이 Poky이다. 기본적으로 Poky를 설치하면, Bitbake가 있고, OpenEmbedded-Core에서 사용했던 Metadata들이 Poky에 맞게끔 수정이 되어 들어가 있다. 이 Poky를 기반으로 Yocto Project가 나오게 된다.

 

Poky

- Yocto Project의 레퍼런스 빌드 시스템

- 플랫폼에 독립적이고 Bitbake, OpenEmbedded-Core와 Metadata를 사용하여 Cross Compile을 수행한다.

---

Yocto Project Development Environment

IMG1 - Yocto Project Development Environment

 

IMG1 그림 한장을 통해 Yocto Project가 어떻게 build를 하고, 결과를 내보내는지 설명할 수 있다.

Upstream Project : (강의상류:sw가 수정이되고, 릴리즈가 되고, 배포가 되는 흐름을 강으로 비유) 최초의 Open source를 만든 시작점. Yocto는 대부분 source를 Upstream에서 받아온다. 예를들어 ALSA(Advanced Linux Sound Architecture)의 source를 받아온다고 가정하면, ALSA 공식 홈페이지에서 제공해주는 Git repository로 부터 tar(Tape Archive) file받아온다. Downstream은 해당 Upstream을 받아서 수정해서 최종 유저단에 배포하면 그곳이 downstream이 된다. Local Project : Recipes안에 tar 파일 하나 넣어도 그것으로 빌드가 가능한 project. SCMs : Software management system [SVN, Git...] Source mirror를 통해 소스를 다운받게 되어있다. 예를들어 해당 지역의 인터넷 속도 문제로, Upstream에서 다운받아 빌드하기가 어려운 환경이다. 이 때 Local Project로 빌드가 가능한 Yocto를 제공한다. repo sync를 하면 그 안에 Source Mirror란 디렉토리가 있다. build를 하게되면 기본적으로 Recipes에 정의된 Upstream이나, SCM에 정의된 주소의 특정 revision을 가지고 오라는 order들이 정의되어 있는데, 그 값과 Source Mirror에 있는 값과 비교 후 같으면 다운로드를 받지 않고, symbolic link만 걸어서 그 다음 절차로 넘아가게 된다.

Source를 Fetching(Download)을 하고, Patch(Recipes에 정의된 배치 파일들을 적용해서 자동으로 Patch를 수행하게 된다)를 하고, Configuration을 하게되는데, Autotools를 상속받은 경우에는 Configure를 수행하고, Make를 수행하는 단계를 거치게 된다. 이 단계를 거치게 되면 실질적으로 Compile이 완료되게 된다. Complie 완료 후 Make install을 하게된다.

Make install하기 까지의 과정들에 대한 환경 설정들을 할 수 있는데, 다음과 같은 섹션에 따라 설정이 가능하다. User Configuration : 사용자들이 추가적으로 어떠한 옵션을 빼고 싶을 경우 Remove, 추가하고 싶을 경우 Append 사용 Metadata :  .bb file or patch file을 의미함. Machine(BSP) Configuration : Board Chipset 설정에 대한 정의 및 설정에 따라 동작하는 방식을 정의하게 된다. Policy Configuration : ?

Make install(Do install) 실행 AutoTools를 다운로드 하게 되면 Make install을 수행하게 되고, 그게 아닌 경우는 Do Install이라는 Task를 사용자가 정의를 하여, 필요한 위치에 복사가 되도록 script를 넣어주게 되면, 알아서 install이 된다. 작업 directory까지 가면 images라는 directory가 있으며, 그곳이 destination install directory가 된다. 그 안에 files을 복사하게 되고, 그 다음 packaging 단계에 돌입한다. Package의 제일 큰 목적은 rpm package를 만드는 것이다. 그래서 package라는 directory로 files들을 이동 시킨 후, 어떠한 package를 제공할 것인가? 기본 package는 'project name', 'project-name-deb', -dbg, "development version", "debug version", "runtime version" 세개가 기본적으로 분류가 되며, Library의 경우 Static Lib라는 패키지가 생길 수 있다.

package를 분류하는 이유 단순히 ALSA만 설치하여 aplay를 사용하면 모르겠지만, GStremaer 빌드가 필요한 경우. 이럴경우 ALSA deb를 설치해야 가능하다. 그래서 package를 분류하는 것이다. package를 분류하여 rpm을 만들면, Package Feeds에 package들이 설치(tmp/deploy/rpm)되게 된다. 이곳에 모든 rpm들이 설치가 되어 있다. 추가적으로 build시점에 dependency가 필요한 경우, Recipes의 Depends라는 환경변수가 있는데, 이곳에 지정을 하게 되면 sys-root를 참고하여 컴파일하게 된다. Yocto project에서는 크로스 컴파일링 하는 기본 컨셉이 sys-root를 특정 directory로 지정을 하여, 그 안에 ARM으로 크로스 컴파일 된 library부터 시작해서 헤더파일 까지 모두 존재하게 된다. Depends로 정의된 package는 추가적으로 sys-root로 설치가 된다.

Image Generation RPM들이 설치가 된 후 Image를 만들게 된다. Image Generation은 bbClass를 상속받은 bb 파일을 bitbake로 실행을 해야 수행된다. 예를들어 빌드 가이드에 나온 bitbake autimotive-linux-platform-image라는 것을 명령하면, bitbake는 autimotive-linux-platform-image.bb 파일만 열게된다. 그리고 그것을 parsing 한다. 이 단계에서 필요한 package들을 찾게 된다. 만약 GStreamer 또는 QT를 사용한다고 명시하였는데, Package Feeds에서 해당 rpm들을 찾아본다. 만약 존재하지 않는다면? 빌드를 해야겠네 라고 판단을 한 후 Recipes를 뒤져보게 된다. Receipes를 찾은 후 그 Recipes에 해당하는 Source Mirror는 무엇이지? 그곳에서 Source를 다운로드를 받고, 컴파일을 해서 RPM을 만들고 Package Feeds 쪽으로 옮기게 된다. 필요한 RPM를 모두 획득 후 그 때 이미지를 만들게 되는데, 만드는 방식은 일반 리눅스 배포판 패치키 인스톨과 동일한 방식을 수행하게 된다. 지금은 "SMART"라는 RPM Package management를 사용하게 된다. 그래서 이미지를 만들때 "SMART"가 실행이 되고, Package Feeds에서 필요한 RPM들을 특정 디렉토리에 설치를 한다. 특정 디렉토리 RPM를 다 설치하게 되면, 그 디렉토리를 기준으로 ext4,tar,ex3 등 이러한 file system format으로 만들게 된다. 이때 이미지가 생성되며, 생성된 이미지는 tmp/deploy/images/ 에 존재하게 된다.

SDK Generation 흔히 ADT라고 얘기를 하며, Image Generation까지의 과정은 System 개발자 측면의 관점이며, 추가 Application 개발 사이드에 필요한 환경을 제공하기 위해 SDK Generation이 담당한다. 만들어지는 방식은 Image 생성과 동일한 방식으로 만들어진다. Dependency를 찾고, RPM을 만들어서, RPM들을 모아 SDK Generation을 하는데, 이때 만들어지는 Output은 "Script"이다. 해당 Script 안에는 모든 Library가 다 들어가 있다.(QT/GStreamer/Header files/Compiler/etc...) Script 하나만 실행하면 Cross Compile을 할 수 있는 환경을 실행(구축)하게 된다.