慣れてきたデバイスツリー

組込

DTCコンパイラ
・双方向。dts→dtb, dtb→dts どちらも可。
・実は、dtc自体は、たいしたことはしていない。生成後のバイナリ（.dtb）をhexdump -C等で確認すれば分かる。
・主要ディストリでは、パッケージで配布されている。Debian系ではdevice-tree-compiler、CentOSではdtc。
・Ver 1.4以降で、バージョンの差異が少しあるが、問題にならないケースが多い。

トラブルシュート時のコツ
・デバイス調整がらみではまったら、まずはデバイスツリーを見る。但し、SDRAMパラメータは別格で、デバイスツリーでは扱わない。
・デバイスツリーで定義されたパラメータが、本当にKernelやU-Bootで使われているか、grep検索で確認する。
・互換性重視のあまり、無駄な記述が多い。
・ダウンコンパチ的な記述配慮は簡単。単に列挙すれば良い。
・パラメータ名の中途にあるカンマ「,」はフェイクであり、通常のテキスト扱い。
・使うKernelに含まれているdtsサンプルを参照する方が良い。但し、H/Wやデバイスに依存する数値はベンダ・H/W設計者から提供を受けた数値を適用すること。

その他：
ラズパイではデバイスツリーの一部を/boot/config.txtで定義できる。何故テキストのまま引き込まれるのか、いつか調べたい。

エアロビ・ダンス中の「気」の意識事項

脱力モード

かかりつけ医からの助言でスポーツジムへ通いはじめたのは２年半前でした。初心者向けクラブＨで１年半、そして、昨年11月にクラブＫへ移って１年経ちました。Ｋに入った当初はターンもおぼつかない状態でしたが、今は自信を持って回れます。ＨでもＫでも、インストラクターの先生は、声がかれている時でもエネルギッシュかつ丁寧に指導します。我々サラリーマンは風邪をひけば休暇をとりがちな中、本当にありがたいことです。

以下、エアロビ・ダンス中の意識事項の備忘録です。ダンスは、MegadanzとBodyJamです。個人指導は受けておらず、素人感覚丸出しの内容です。

１．腹筋
体の軸であり、最も意識します。「丹田」「重心上」で意識することもあります。ラテン系の動きでは、特に意識しています。

２．脱力
私の場合、ターンがうまくいかない時は、たいてい、力が入りすぎています。新しい振りを覚える時に、脱力を意識してうまくいくこともあります。

３．あごを引く
テニスやスキーでは最優先事項でした。集中力が鈍ってきた時に、意識するようにしています。但し、意識しない方が良いシーンもあり、「脱力」とのバランスになります。

４．手のひらの付け根
ここに「気」を持つことで、アームを中心とする体全体の動きがスムーズになりました。最近、意識するシーンが多いです。

５．心の軸
心が浮ついている時は怪我をしやすくなります。心の軸は、感謝の心。いつも丁寧に指導してくださる先生に感謝、語ることは無いけど共に健康維持に取り組む仲間に感謝、五体満足に動く自分の体に感謝し、謙虚な精神状態で臨みます。

rootkit hunter

Linuxの小技 ネットワーク技術 組込

ちょっと気になったので、Ubuntuホビーマシンで久々に実行してみた。以下、root権限のsudoは省略。

apt install rkhunter
vi /etc/rkhunter.conf

UPDATE_MIRRORS=1
MIRRORS_MODE=0
WEB_CMD=""
PKGMGR=DPKG
SCRIPTWHITELIST=/usr/bin/lwp-request

rkhunter --update
rkhunter --propupd ## <= /etc/rkhunter.confを変えたら実施
rkhunter --versioncheck
rkhunter --checkall --skip-keypress
または
rkhunter -c --rwo --sk

Warningが少し出たので、/var/log/rkhunterを確認し、必要に応じて処置する。

例えば、、、
Warning: The SSH configuration option 'PermitRootLogin' has not been set.
とあるが、rootログイン自体を認めていないので、これは無視しても良さそう。
・・・とは思ったものの、念のため/etc/sshd_configを処置した。

/var/log/journalは移動できない

組込

systemd以降、OSログは/var/log/journal以下へ保存される。圧縮ファイルになるが、それでも、放置していると、かなりの量になる。4〜5年運用している私のホビーマシンでは、860MBの蓄積があった。

組込では、ログ領域を移動したいシーンが時々ある。まぁ、どこかに設定ファイルがあって、移動は簡単だろうと思いきや、調べてもなかなかパラメータ設定が出て来ない。ユーザランドをgrep検索しても設定ファイルが浮き上がらない。

まさかとは思いつつ、systemdのソースコードを見たら、その、まさかのコチコチのハードコーディングだった。
例）https://github.com/systemd/systemd/blob/master/src/journal/journalctl.c

それでも無理やり移動させるなら、systemdが実行される前に、/var/log/journalのマウントポイントを変えるしか無い。それを実施できる機会は、初期RAMDISK（initrd）内でのスクリプトである。initrdが無いプラットホームでは、Kernel起動パラメータ「init=」で/sbin/init以外の自作スクリプトを指定し、そこで対処する。

備考：
Kernelが最初に走らせるプログラムは/sbin/init。初期RAMDISK(initrd)がある場合は、initrdに含まれる/sbin/initとスクリプトが実行され、最後にHDD等のユーザランドにchroot（pivot_root)される。その時に、今度は、HDDの/sbin/initが実行される。そのHDDの/sbin/initは、systemdへのシンボリックリンクである。

DeviceTreeの存在意義が分からない！ その2

組込

DeviceTreeの影響はペリフェラルだけかと思っていたが、そうでもないらしい。

例えば、ARMデバイスツリーに対するこのパッチ。それに対応するカーネルソースのパッチ。これをデバイスツリー側で処置せずにカーネルバージョンアップすると、CPUが1コアで動くことになるかもしれない。

それに、デバイスツリーのここ。それに対応するカーネルソース側はここ。


Linuxは、横の汎用性は重視するが、縦の互換性（バージョン互換性）は容赦なく見捨てるので、バックポートのインパクトが大きくなる。常に動向を追うのは限界で、日本で組込Linuxやっている人は、この分野で孤軍奮闘一匹狼片手間という状況？なので、ちょっとつらいが、構成管理物が1個増えたことを認識し、あきらめてつきあっていき、慣れるしかない。

DeviceTreeの存在意義が分からない！

組込

以下の話は、x86系CPU（ATX規格のPC）は対象外。

私の立ち位置では、DeviceTreeの存在意義が全く分からない。

DeviceTreeとは、ハードウェア設定をスクリプト形式で記述し、Kernelへ橋渡しすることで、ハードウェアの差異をスムーズに吸収することを狙ったものである。Intel PCには無く、ある時期以降のPowerPCとARMで利用されている仕組みである。組込Linuxでは、U-BootとKernelの間に位置する。

ディベロッパーサイドで言わせてもらうと、これは、混沌しか生み出していない。そもそも、U-BootとKernelの間だけであっても、ペリフェラル設定をどちらが実施するかで悩むことがある。Ethernet関連やPCI関連のデバイス設定は、U-BootとKernelで重複設定しているケースや、邪魔しているケースもある。そこへ、DeviceTreeが割って入って来たので、混沌しか生まれない。Kernelがデバイス設定パラメータを受け取るルートが増えただけである。

例えば・・・、LANのPHYチップにRGMII/SGMII等の高速インタフェースがあるケースでは、たいてい、デバイス設定でスキュー調整を行うが、この設定ルートになりうる下記の①〜④が、カード種別／PHYチップ／Kernelバージョンでばらばらである。しかも、重複設定もある。

① U-Boot → Kernel
② Kernel内単独でパラメータ設定
③ DeviceTree → U-Boot → Kernel
④ DeviceTree → Kernel

昔は①か②であったが、②だけでは、U-BootでLANが使えず、開発ではNG。U-Boot側での設定は必要。その意味では、④もNG（または重複設定）。

更に、構成管理物が１個増え、それがH/WとS/Wの中間にあるものだから、ハード屋／ソフト屋どっちで開発・管理等めんどうを見ていくかでもめることになる。

Linuxの第一理念である汎用性を狙ったものなのだろうが、DeviceTreeによって何か恩恵を受けた人は、はたしているのだろうか？。

https://www.devicetree.org/specifications/

もしDeviceTreeが無かったら・・・
https://youtu.be/UURuqxzuEls?t=1013
どうやら、Kernelツリーにおけるソースコードの膨張を吸収する役割を果たしているようです。例えば、ボードに特化したパラメータの入ったパッチはKernelのソースツリー本体にはコミットされず、そうしたボード固有情報はDeviceTreeに外出しさせることで、ソースツリー本体のバリエーション拡大や#define列挙でのコード増大を防いだのでしょう。別の立ち位置から見ればDeviceTreeの存在意義はあるわけであり、T様の怒りを沈めるべく尽力された方々に深く御礼申し上げます。

ダイアリーからブログへ

先週、はてなダイアリーだけアクセスできない時がありました。バンされたかと思ったのですが、そうではなかったようです。おそらく北海道にホストがあるのだと思います。

その時にはじめて知ったのですが、ダイアリーは、来年終了とのこと。そろそろ、ダイアリーからブログに引っ越します。

「はてなダイアリー」と「はてなブログ」は、微妙に違います。実は、別の趣味の記事は、ブログに書いています。ブログのほうが、スマホで見るには確かに良いです。ただし、技術論を書くには、こちらの方がデザイン的に好きでした。

新しいブログサイトからインポートする方法で移行する予定ですが、一部はQiitaに移動するかもしれません。