시간이 좀 오래 지나긴 했지만, 간간히 yocto 관련글이 있어서, 다른 분들에게 조금이나 도움이 될까봐 사용기를 남깁니다.

우선 yocto를 사용하게된 계기는 예전 회사에서 임베디드 디바이스 제품을 개발하는데, os를 리눅스를 올리는 것으로 결정을 하게 되었는데,  반대는 했지만 어른들의 사정으로 yocto개발을 진행하게 되었습니다.

우선 저희가 yocto를 반대 했던 이유는 방대한 레시피 파일과 자유로운 커스터마이징이 가장 마음에 걸렸고, 방대한 레시피에 의해서, 부차적으로 발생 할 수 밖에 없는 학습시간은 도저히 견적이 불가능 할 정도 였습니다.

어쨌든 업무는 진행을 해야 했고, 상황은 이상하게 돌아갔지만, 개발은 했습니다.

처음 yocto를 접했을때 느낀게 몇가지가 있는데, 그중에 첫번째가 거대하다 입니다.

현존하는 모든 opensource 프로젝트는 모두 포팅되어있다 라고 느낄정도로, 제가 알고 있는 거의 대부분의 opensource는 레시피로 만들어져 있습니다. 이게 장점이기도 하고, 단점이기도 한데, 장점은 buildroot나 ltib에서 처럼 뭐 하나 포팅하는데 삽질하는게 별로 없습니다. 그냥 레시피 딴거 참조해서 넣으면 됩니다. 단점은 이 모든 package들을 누군가는 다 파악해야 됩니다.

두번째는 빌드 시간이 무지막지 합니다. 엄밀히 말하면, 빌드 시간보다는 source package를 다운 받는 시간이 더 걸리기는 했지만, yocto 프로젝트는 linux 이미지를 빌드 하기위한 레시피를 제공하는 것이 아니므로, 각각의 개별 package를 각각의 repository에서 다운받는 구조로 되어 있어서, 이 시간이 재수 없으면 하루 넘게 걸릴 수도 있고, 미러에서도 못 받는 경우도 생겨, 빌드가 불 가능한 상황을 맞이 하는 경우도 있습니다.

세번째는 BSP 또는 테크리더의 역할이 매우 중요합니다. 다를 개발도 마찬가지 겠지만, yocto 개발에서 BSP의 역할이 매우 중요했습니다. 즉, 커널을 포팅하고 보드의 눈을 띄우는 작업 뿐만이 아니라, 전체 빌드 프로세스는 어떻게 잡을 것인지, SDK를 어떻게 배포 할 것인지, 배포된 SDK를 이용하여 application 담당자들은 어떤 방식으로 개발하고 디버깅 해야 하는지 가이드를 해줘야 합니다.

여러가지 고민도 하고, 삽질도 하면서, 개발 방법을 세우고, 개발을 진행 했습니다.

우선 CI서버와 연동시키는 상황에서, build os의 버전 특성을 타고 있어서, 빌드 환경은 docker에 밀어넣고 build host가 바뀌더라도 영향을 받지 않도록 하고, CI 서버에서 매일 새벽에 daily build를 진행 했습니다. sdk를 얼마나 자주 배포 할 것인가의 고민도 잠깐 있었지만, 어차피 application 별로 의존성이 거의 없어서, 자주 배포를 하진 않았습니다. 개발자들이 소스를 push 하는 순간 커밋 빌드도 돌릴까 했지만, 서버의 로드가 너무 많이 걸려 이건 적용하지 않았습니다.

opensource package source는 다운로드에 문제가 언제든지 발생 할 수 있습니다. 즉 어제는 잘 됐는데, 오늘은 암 것도 안했는데, 빌드가 깨진다거나 그 반대의 경우도 얼마든지 발생 합니다. 따라서, 다운로드 실패에 의한 빌드 실패를 방지 하기 위해서, 내무 mirror와 download cache를 이용해서, 다운로드 시간 절약과, 실패를 방지 했습니다.

yocto 이미지 커스터마이징은 처음에는 poky나 벤더에서 제공된 레시피를 수정하거나, source를 수정하는 형태로 진행 했는데, 익숙해 지고 나니 전혀 그럴 필요가 없었습니다. 오히려 원본은 원본대로 수정은 따로 meta-packag를 분리해서 개발 하는 것이 더 효율적이라는 것을 확인 했습니다. 처음에응 이해가 잘 안되는데 gentoo의 portage 시스템을 통해서 이해를 했습니다. 원본이 존재 하고, overlay로 레시피에 append/prepend 로 덮어쓰면, yocto 시스템의 변경사항을 받아 오면서도, 개발하고 있는 시스템에 문제를 최소화 시킬 수 있습니다.

application 개발은 각 개발자들이 배포 받은 SDK를 이용하여, 개발을 진행하고, 개발툴은 qtcreator를 이용하여 개발 했는데, 지금이야 CLion도 있고, vscode도 있지만, 몇 년전 까지도 딴 툴은 없기도 하고, 결정적으로 IDE의 역할을 해줄 수 있는 툴은 qtcreator가 유일했습니다. vim이나 sourceinsight를 이야기 하는 사람도 있는데, 코딩/배포/디버깅 까지 단한번의 클릭으로 할 수 있는 건 무료 툴에선 이게 유일합니다. 일례로 cmake crosstoolchainfile이나, qmake mkspec만 잘 만들면 wince 개발 할 때 처럼 개발이 가능 해집니다.

네트워크는 target 시스템의 usb-otg를 이용해서 개발하는데, linux에서 usb gadget 디바이스를 제공해줘서, usb to usb를 usb over network로 사용이 가능 합니다. 단점은 target이 리셋 될때 마다, 윈도우즈 에서 디바이스를 새로 잡는데, 잡을 때마다, ip를 새로 지정해줘야 하는데, 이부분은 target dhcp 서버로 동작하게 해서, 별도의 입력이 없어도 동작이 가능 하도록 했습니다. (사무실의 네트워크 공사를 새로 할 수도 없고, 네트워크를 어떻게 해야 하나 고민하고 있었는데, beaglebone black 보드에서 힌트를 얻었습니다.)

yocto로 개발하면서 우여곡절이 많기도 했지만, 극한의 커스터마이징도 가능해서, 매우 만족할 만한 결과물을 만들어 낼 수 있었습니다. scratch나 buildroot/ltib면 꽤나 고생했을 껀데, 쉽게 해결이 가능한 부분도 많았습니다.

지금은 리눅스 쪽 개발일이 없어서 손을 놓은지 좀 됐는데, 가끔씩 yocto 어떠냐고 물어 보면, 내가 개발하면 yocto로 개발 하겠지만, 남들에겐 추천은 못하겠다. 라고 합니다. yocto 시스템을 이해 하려면, 기본적으로 gentoo를 stage1 부터 설치해보고, 개인적으로 몇년씩 사용하면서 기본적인 트러블 슈팅은 할 줄 알고, 현재 사용하고 있는 시스템의 백그라운드 프로세스의 이름과 역할을 다 알아야 합니다.

가끔씩 yocto 관련 글이 올라올때 마다, 삽질의 끝판왕이라 그러는데, 진짜 그말에 백번 동감합니다.

근데, 이번에 제품 만들껀데 os 뭐 쓸까요? 라고 물어 본다면, 저는 yocto 라고 대답할 정도로, 잘 정돈되고, 제품화 하기 위한 커스터마이징이 자유로운 플랫폼이기도 합니다.

이상 yocto 리눅스 사용기(?) 였습니다.