Buildrootのドキュメント斜め読み　Chaper8

Chapter 8. Buildrootの使い方

8.1 make tips

他章のものを記載する

コマンド	内容
make help	サブコマンド(target)を表示する
make V=1	makeで実行されるコマンドの表示
make list-defconfigs	各ボード用に利用可能なmenuconfigを表示する
make clean	対象アーキテクチャやツールチェイン変更時に使用する
make ckean all	再フルビルド実施
make manual	docs/manualに生成されるマニュアルの生成
make manual-clean	マニュアルのクリア
make distclean	ターゲットのクリア
make -dirclean	パッケージの削除
make source	`dl`フォルダ配下からオフラインビルドする
make O=	outputフォルダを指定する
make graph-depends	依存関係のグラフを生成する

8.2 フルビルドし直すタイミング

下記でも必ず必要ではないユーザが適宜判断し実行する * アーキテクチャが変わったとき * ツールチェイン設定変更 * 依存するライブラリ追加する * パッケージのサブオプション変更時 * RFSのスケルトン変更時

8.3 パッケージの再ビルドについて

パッケージの削除は再フルビルドするしかない
- stagingとか関連する場合
- 単体で削除可能ならoutput/buildから削除するかmake <package>-dircleanでもよい
- output/build/<package>-<version>/配下にビルド状態を管理するスタンプファイルstamp_<step-name>を生成する

8.4. Offline builds

8.5. Building out-of-tree

(makeのサブコマンドのであるため省略)

8.6. 環境変数

(関連する項目で見るため省略)

8.7. 効果的なファイルシステムの扱い方

sparseファイルについて(よくわからん)

8.8. パッケージの依存関係をグラフ化する

*make graph-depends * output/graphs/graph-depends.pdfに生成される * Graphvizを入れる必要がある * apt install graphviz * システムがでかくなると見づらいのでmake <pkg>-graph-dependsでパッケージ単位で出力するともできる * PDF以外のフォーマットでも出力可能 * BR2_GRAPH_OUT=svg make graph-depends * BR2_GRAPH_DEPS_OPTS環境変数で制御を変更可能

ビルド時間のグラフ化

どのパッケージのビルドに時間がかかっているかを可視化することができる
make graph-build
python-matplotlibを入れる必要がある
数種類のファイルが生成される
build.hist-build.pdf
- 各パッケージごとにかかった時間がビルド実行順にヒストグラムになる
build.hist-duration.pdf
- ビルド時間がかかった順のヒストグラフ
build.hist-name.pdf
- ファイル名順のヒストグラフ
build.pie-packages.pdf
- ビルド時間の円グラフ
build.pie-steps.pdf
- ビルド行程ごとの円グラフ
出力フォーマットは変えれる
- BR2_GRAPH_OUT=png make graph-build

8.10. パッケージごとのファイルシステムサイズのグラフ化

各パッケージのファイルがRFS中に占める割合をグラフ化
生成されるfile-size-stats.csvを利用して、ビルドごとの比較をすることができる ** utils/size-stats-compare -h

8.11. Eclipseインテグレーション

使わないので省略

8.12. 応用

8.12.1. ツールチェインをBuildRoot外で使う

output/host/bin/をPATHに追加するなりする

8.12.2. Buildrootでgdbを使う

設定でgdbserverを有効にするなりすれば使える

8.12.3. Buildrootでccacheを使う

省略

8.12.4. ダウンロードしたパッケージの配置先

BR2_DL_DIRで指定できる

8.12.5. パッケージ単位でのmakeサブコマンド

make <package>-<target>

8.12.6. Using Buildroot during development

<pkg>_OVERRIDE_SRCDIRでパッケージに対してファイルを追加できる

調査はだいぶ前に終わってたけど、しばらく体調を崩していてかけなかった

ここまでの情報でだいたいBuildrootにおけるシステム構築方法を確認することができ、以降はBuildroot自身に変更を加えて独自パッケージ追加するといったこととなるので、ドキュメント斜め読みとしてはここまでかな。

2017-09-15

Buildrootのドキュメント斜め読み　Chaper6~7

Chapter 6. Buildroot 設定

設定の詳細はmake *confing内で確認できる

6.1. クロスコンパイルツールチェイン

２種類のツールチェインに分類される
Buildroot toolchain
- ツールチェインからビルドする
- pros:Buildrootとの連携が柔軟
- cons:設定を変更するとフルビルドが必要
External toolchain
- Linaroなどのベンダーのツールチェインを利用する
- pros:有る程度信頼性があり、ビルド時間も短くなる
- cons:不具合があるとベンダー依存になる

6.2. /dev 管理

configuration, /dev management で/devの構成を変更できる

静的なDeviceTableファイル
- 古典的な方法
- デバイスファイルを予め生成したものを/devに配置しておく
- BR2_ROOTFS_STATIC_DEVICE_TABLEにDeviceTableファイルを指定できる
devtmpfs
- Buildrootでの推奨
- 2.6.32から導入された仮想ファイルシステム
- /devにマウントされ、デバイス追加削除に応じて自動的にデバイスファイルを生成削除する
- CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNTのカーネルコンフィグが必要
devtmpfs + mdev
- Busyboxのmdev(udevの軽量版)がデバイス管理する
- /etc/mdev.conf
devtmpfs + eudev
- mdevより複雑で柔軟な管理制御ができる
initシステムにsystemdを選択するとudevになる

6.3. init システム

System configuration, Init systemから以下３つのInitシステムを選択することができる

Busybox
- Buildrootのデフォルト
- ベーシックなinitプログラム
- /etc/inittabを読み込む
- フォーマットは一般的(symtemV)なものと少し異なるのため、https://git.busybox.net/busybox/tree/examples/inittab を参考にすること
- 主に行うのは/etc/init.d/rcSやgettyの起動
systemV
- 多くのデスクトップLinuxで使用されてきた伝統的なinitプログラム
- /etc/inittabを読み込む
systemd
- 次世代のinitプログラム
- より複雑な制御ができる

Chapter 7. 他コンポーネントの設定

busyboxやLinuxKernelなどの設定ファイルがある場合はBR2_PACKAGE_BUSYBOX_CONFIG.やBR2_LINUX_KERNEL_USE_CUSTOM_CONFIG といったパラメータに指定することができる
- 指定しなければデフォルトの設定が適用される
- 設定はmake busybox-menuconfigとかで変更できる

現状は軽量な組み込み最小構成のLinuxシステムを想定した起動や/dev管理となってるような雰囲気。
ぼちぼちLinuxの知識が必要だったのと次章はmakeコマンドtipsが多いのでここまで。

2017-09-14

Buildrootのドキュメント斜め読み　Chaper1~5

Rapi上でカスタマイズしたLinux動かしたい気持ちがあったけど、自前でカーネルビルドからRootfs作成までやるのが面倒だと思って中々手をつけれていなかったのですが、Buildrootなるツールがあったので、それを試している最中。

Buildroot - Making Embedded Linux Easy

現状、ドキュメント通りにRaspi3向けのSDカードイメージを焼いて起動させるとことまでいった進捗

buildeootイメージのラズパイ3と昨日届いたタッチディスプレイがつながったので、週末の準備は終了。
ぅてか、初期設定のビルドのイメージだと5秒でログインまで行くな。軽い〜〜 pic.twitter.com/RSAIX7BrdF
— STC (@stc1988) 2017年9月13日

とりあえずドキュメントを見ながら色々試していくかー、という感じですが、どこまで読んだか忘れしまうで、自分が気になった点をつらつらとメモしていこうと思う。

実際に試してみた結果も差し込むなりしていきたい。

The Buildroot user manual

Chapter 1. はじめに

Buildrootは組み込みLinux用環境をビルドするための一連のプロセスを実現するツール
様座なボード向けのデフォルト設定を提供している

Chapter 2. システム要件

Linux上で動作するように作られている
実施に必要なパッケージは別途入れてくれ(必要パッケージについては省略

Chapter 3. Buildroot入手

３ヶ月ごとにtarball形式でリリースされる(http://buildroot.org/downloads/
最新リリースでのBuildroot環境を生成するためのVagrantFileを使用すると便利

実際にvagrantで環境構築したので、依存パッケージとかも何も考えずに先工程を実施できた

Chapter 4. クイックスタート

通常ユーザ権限で実行できる(sudo不要
最初にコンフィグレーションをするためのツールがいくつのインターフェイスで提供されている ** make menuconfig などをBuildrootのディレクトリで実行
コンフィグ情報は.configファイルに生成される
make でビルド実行
make -jN は使用しないこと。代わりにBR2_JLEVEL optionを使用する。
ビルド結果はoutputディレクトリ配下に生成される

Chapter 5. コミュニティ

(省略)

今回は触りの部分まで。ここからはは起動周りの話やmakeコマンドの使い方、開発者向けの独自パッケージ追加？など。

2017-07-17

Google Data Studioで体重測定結果をいい感じに可視化する

ことのキッカケ

今まで使っていたWifi対応体重計を販売していたWithingsがNokiaに買収された。

Withings is now Nokia

それにともない、Webのダッシュボードアプリをはじめ、スマートフォン用のアプリも「Nokia Health Mate」というアプリに一新した。

が、しかし、今まで使えた機能が使えなくなったりと、評判が悪い。

特定の製品やサービスに頼ってると、今回のような急な買収等により使い勝手が悪くなったり、最悪データが見れなくなるケースもあるので、出来れば生のデータを手元に保持して扱えるようにしておきたい。

そこで、貧者のデータベースであるところでおなじみ??のGoogle Spreadsheet と、それを使って良い感じにデータ可視化をできるGoogle Data Studioを使うことにした。

データの取得

IFTTTのWithingsインテグレーションを使って、これから体重計では測ったデータは、指定したSpreadsheetに追記するようにする。

で、これまで計測したデータだが、Nokia Healthのウェブ版やアプリからのエクスポート方法が見つからないかと思ったが、ググると以下ページのリンクからエクスポートができた

support.health.nokia.com

エクスポートしたzipファイルには数個のcsvファイルが含まれるが、今回はweight.csvをSpreadsheetに取り込んだ。

日付のフォーマットが2017-07-14 15:22:54となっているが、IFFFから通知される日付はJuly 03, 2017 at 07:40AMといった書式となっているので、IFTTTのフォーマットに会うようにTime::Pieceモジュールを使ってサクッと変換をした。

Spreadsheetは、以下のような平凡なフォーマットとなった。

f:id:stc1988:20170717203552p:plain

[余談]iOSヘルスケアのデータエクスポート

iOSのヘルスケアアプリの生データもぶっこ抜きたいなー、と思っていたら、普通に自分のデータ表示のページからデータの書き出しが行える。書き出し先にiCloudDriveが指定できるのでマジで便利だ。

出力したzipファイルを展開するとxmlファイルが２つ入っていたが少々問題が発生した。

iPhoneのヘルスケアで取得している歩数やらのデータをPC上に持っていきたいが、書き出ししても全然データ入ってないやん
— STC (@stc1988) 2017年7月12日

IOS10.3 ヘルスケアデータを書き出す、でデータが取り出せない | 公式 Apple サポートコミュニティ https://t.co/NxiW8rfrOA 設定言語の問題らしく、英語に変更して書き出したらいけた。
— STC (@stc1988) 2017年7月12日

90MBほどのXMLファイルをどうやって処理するか。
— STC (@stc1988) 2017年7月12日

データはXMLだけど、データ構造としての価値はあまり無さそうなので、素直に行単位でGrepするのが手っ取り早い気がする。

Google Data Studioで表示する

新しいレポートを作成し、データソースに先程作成したSpreadsheetを指定する

f:id:stc1988:20170717204514p:plain

Spreadsheetの１列がデータ表示のための１フィールドとして認識されている。

既存のフィールドを利用した追加のフィールドもデータソース側を弄ることなく、数式を書いたりして柔軟に追加ができる。

今回は、

測定回数として、データの件数
体脂肪率として、体脂肪量 / 体重

をフィールドとして追加した。

後は、フィールドを指定しながら、グラフやスコアボードを配置していく。

時系列データは、毎日のデータが無いとガタガタのグラフになるので、「スタイル->欠落データ->線形補間」をしておくとよい。

各データ表示は期間を柔軟に指定ができ、現在と直前の期間の差分もすぐに表示できるので、可視化する作業が気持ちいい。

テンプレートも真似しつつ、以下のような形となった。

f:id:stc1988:20170717205402p:plain

今後はデータソースをもっと増やしていき、自分の状態を測るダッシュボードとして拡充していきたい。

2017-07-09

YAPC::Fukuoka 2017 HAKATA行ってきました

前回のKANSAIはスタッフとして参加し、今回は一般参加者として行ってきました。

yapcjapan.org

前日

有給を取り、朝一で新大阪〜博多へ新幹線で移動。

JTBで、ひかり・こだま指定席限定で半値でいけるプランがあったので、安く行けた。

www.jtb.co.jp

マリンワールド

朝一でついてやることもなかったので、駅メモついでにマリンワールドという水族館へ行ってきた。ちょうど、その日はとても暑かったので涼しく過ごせた。

イルカが空を飛んでいる。 pic.twitter.com/3PiPruE9yH
— STC (@stc1988) 2017年6月30日

やはり、ペンギン🐧は可愛い😍 f:id:stc1988:20170709121931j:plain

全然野菜

pepabo.connpass.com

場所や時間を勘違いしながらも汗だくでペパポさんに行くと関西の顔なじみ達と合流した。

songmuさんの「Mackerelのプラグインの容量を削減した話」が良かった。 GO言語はシングルバイナリで配布出来る一方、ファイルサイズにオーバーヘッドができやすいので、バイナリ数が増えると容量的に厳しいという問題に対して、１つのバイナリにして、呼び出し引数で実行されるプログラムを切り替えるという、古き良きBusybox的なアプローチで解決していた。

言われてみれば、あーなるほどだが、発想と言うか引き出しの広さの重要性に気付かされた。

前夜祭

チケットを確保し忘れたので、参加できず。 TLでも前夜祭、懇親会チケット難民が確認できたので、「みんな、チケットお買い求めはお早めに！！」とスタッフ経験者的にも思いました（自戒

よって前夜祭会場隣で🍣を食べて帰りました。

I'm at 立食いすし屋の魚 x 3 in Chuo-Ku, Fukuoka, Fukuoka https://t.co/9D5rmPnfZm
— STC (@stc1988) 2017年6月30日

当日

f:id:stc1988:20170709123755j:plain

福岡LINEさん、広い！キレイ！オシャレ！といった感じで、少ないカンファレンス参加経験ながらも一番良い会場だったと思う。腰痛持ち＆飽き性としては、メイン会場が広々してたので、カフェのドリンク片手に立ち見したり、ソファーでゆったり見たりと、終始空間的にリラックスできたのが良かった。

トークの方ですが、最近少しWEBを触り始めた程度のレベルなので、全般的に難しい内容であったが、特にmoznionさんのエラーメッセージの話は面白かった。

YAPC::Fukuoka Hakata 2017にてWeb Application Good Error Messageというタイトルで話してきました - その手の平は尻もつかめるさ

エラーメッセージをレベルに分類しつつ、開発者・利用者に対してどう提示すべきかみたいなこと、今の業務では全く手をつけれていないので、参考にしていきたい。

あとは、同じ関西でPerl入学式のサポーターをしていらっしゃるtomchaさんのトークも素晴らしかった。

tomcha.hatenablog.jp

自分が今こうやってYAPCに参加しているのもPerl入学式に出会い、社外のエンジニアの知り合いも増え、自分の活動範囲が広がっていった結果だと思うので、コミュニティや自ら行動していくことの大切さが染みた。

スペシャルセッションは、福岡のIT企業が集まってディスカッションをしていたが、実際に福岡という街は良い街だという印象も受けるし、技術コミュニティの規模は東京に比べたらまだまだ小さいけど、これから盛り上げていくんだいう勢いが感じられた。

一方で、自分が今働いている関西は、それなりエンジニアの数もいて、素晴らしい人も多いけど、この先はどうなるのか？みたいな不安を感じることがあった。KANSAIでは温故知新というテーマにエンジニアの掘り起こしを狙ったけど、これから先の関西は？みたいな話はなかったので。

クロージングでは、ノベルティに入っていたサイリウムをみんなで振るという謎のイベントがあったが、妙な一体感が生まれた気がしたので趣があった。

懇親会

TLでは見かけるけど、直接お話をしたことがなかった人と話す機会があったりと、YAPC行くたびに顔見知りが増えていくのはよいなーと改めて感じた。二次会でいったお店では、ラーソーメンなるものが旨く、博多の夜は最高に楽しかった。

f:id:stc1988:20170709131020j:plain

まとめ

全体を通してとても快適にすごくことができ、会場提供のLINE様のホスピタリティやスタッフの方々の尽力のお陰様で、ありがとうございました！！という気持ちでいっぱいです。

次回は、沖縄・恩納村です。 yapcjapan.org

行ければ初沖縄となるので楽しみです！！

2017-03-08

YAPC::Kansai 2017 OSAKA でスタッフとして参加しました ~前日・当日編　#yapcjapan

yapc yapcjapan

YAPC::Kansai 2017 OSAKA でコアスタッフとして参加しました。 Perl入学式つながりでKansai.pmの若林さんにお誘い頂きました。ちなみにYAPC歴は、2015TOKYO参加のみ。カンファレンススタッフも初経験です。

本記事では、スタッフとして前日・当日の振り返りとなります。それまでの準備とか、全体を通しての感想とかは後日別記事にでもできたら、と。

前日

ノベルティ準備

前日準備のメイン作業。会場に搬入されたノベルティをトートバックに詰め込む、各種Tシャツをサイズごとに畳み仕分けておく。２００個ほどを準備するのは大変そうに思われたが、シール類をひとまとめにした渡す人がいたり、Tシャツを畳むのも並行して終わるように人を割いたりと、今までのノウハウが活かされている感があり、効率的に進めることができたので、あっという間に終わった。段取り重要。

前夜祭準備

参加者に提供する、たこ焼きを事前に予約していたので、それを取りに行った。今回のたこ焼きは、西中島の十八番というお店。天かすがたくさん入っているので外はさくさくした食感で中は出汁がきいて美味しい。

I'm at たこ焼十八番大阪西中島本店 in Osaka, 大阪府 https://t.co/9b3J3Jjaim pic.twitter.com/8nRTWvNTVv
— STC (@stc1988) 2017年1月22日

だいたい５０人前のうち、３０人前ぐらいを冷めないように大きなダンボールに入れてもらったのですが、たこ焼きも嵩張ると案外重かった。

私は前夜祭自体には参加しなかったので、他の参加しないスタッフと大阪へご飯を食べに行き前日は終了。

当日

会場準備

当日は会場に朝８時集合。~~前日飲みすぎて~~朝起きれるか心配だったが、本能赴くままに起きてすぐ新大阪に向かい会場前のコメダへ。

モーニングをキメている pic.twitter.com/5Hqij3xMlT
— STC (@stc1988) 2017年3月3日

腹持ちもいいし、小倉トースト最高！！

私は懇親会番長(主担当)だったので、特に受付や部屋単位での仕事の割当は無し。人手が足りなそうなところがあれば少し手伝って、後はぼちぼちトークでも見ておくか、と思いながら準備が本格的に始まった頃には、各部屋であれが足りてない、これが足りてないみたいなのを各部屋間を行ったり来たりしながらフォローしている間に会場時間となった。

会場~本編

会場受付自体は、Passmarketを使い順調に進んでいたが、早速メイン会場へ案内する人が全くいないことが発覚し、オープンニング開始まで誘導係りに。オープンニング後も会場内をうろうろしながら各部屋への案内をしていた。

各部屋ごとの進行や全体向けの連絡事項は、Slackで随時情報共有されているのが上手く機能していて午前の終わりには落ち着いていた印象。

午後も引き続き会場内を徘徊しつつ、会場の案内板やゴミ分別の整備など細々と仕事をこなし、気づけば完全に遊撃手。

懇親会番長とは…… pic.twitter.com/s4Y0K0O3zI
— STC (@stc1988) 2017年3月4日

懇親会

クロージングが終わると同時にタクシーに乗り会場へ。クロージングが少し押したこともあり、受付開始５分前についたが、すぐに参加者が続々とやってきた。受付自体は、事前に本編の会場で済ませてあるので、リストバンドを確認するのみで楽だった。

タクシーで来たのか、御堂筋線地下鉄で来たのかは定かではないが、受付開始１０分ぐらいで６０〜７０人くらいはやってきたので、場所のチョイスは良かったと思いたい。

補足しておくと、本編会場周辺は今回のお店ほどの大きさものがはほとんど無く、逆方向の梅田だと雑踏の中を歩くのがツラそうという判断で江坂をチョイスしています。

あと、参加者の方々に非常に申し訳ないと思ったことが、非常に大盛況すぎて店内が激狭だったこと。お店のキャパ限界の100名に対して100名参加したら、本当に狭くなってしまった。エンジニアたるものみんなPCを始めとした荷物があるので、もう少し、参加人数に対してキャパの余裕のあるお店を選ぶべきだった。

後からお店の人に聞いた話では、ビールのタンクが底をつきそうだったみたいなので、エンジニアはとにかく酒を飲むという知見が得られた。

懇親会後は、会場の撤収組が先に梅田で打ち上げをしていのでそれに合流をした。みんな疲れが吹き飛ぶかのようなハイテンションさに、いい体験をしたという実感が湧いてきた。

まとめ

初のカンファレンススタッフ経験は、何をすればいいのかよく分かっていないなりにも、遊撃スタイルで足を使って稼いだ。スタッフ仕事は、普段のエンジニアリングとは離れた領域にあって、慣れない部分も多いのですが、良くも悪くも社会人生活で様々な雑務をこなしてきた経験が役立ったのか、当日のドタバタするシチュエーションに対して臨機応変にやっていく勘が鍛えられてた。

社会人スキルとしての足腰の強さ、そして身体的な足腰の強さの両方の大切さを実感しました。

そして、次回のyapacjapanは福岡ですね！参加者として楽しむぞー

yapcjapan.org