機能 #1003
未完了kernel config を制約ベースで推論を入れて管理する
0%
説明
https://mastodon.cardina1.red/deck/@lo48576/116257749290143384
kernel config 半手書き勢なんだけど、「tristate で m でも y でもいいので m にしておくやつ」と「tristate だが y にしておかないといけないやつ」があって管理がダルいのよね。
何とかしたいと思ってるんだけど。この週末で何かユーティリティ書いてみるか？
本来やりたいことは「FOO は =m か =y で、 =m, =y それぞれの場合で BAR も同じ値に設定が必要で、どちらの場合でも BAZ は =y の必要がある」みたいな制約の連鎖の表現とパッケージ化。
で、たとえば「FOO とそのための BAR 自体は =m でも良いが、 QUX=y が必要でこれが BAR=y を要求しているので、結果として FOO=m, BAR=y, BAZ=y, QUX=y になってほしい」といった、パッケージを跨いだ制約解決をしたい。
また「CONFIG_FOO=n と # CONFIG_FOO is not set」はどちらでも (私にとっては) 同じことだが、適切な方を選ばないと merge_config.sh が拒絶する」のような問題もあり、これも可能ならどうにかしたいところではある。
現状ではシェルスクリプト (というか sed) によるシンプルな文字列処理による内容結合程度のことしかしていないため、制約を解決したいならマトモな高級言語でちゃんとやりたい。
NO nop_thread さんが約5時間前に更新
- 前回確認日 を 2026/03/20 にセット
kernel config 生成(略記)のためのシェルスクリプト - 何とは言わない天然水飲みたさ
たとえば
CONFIG_FOOが前提条件としてCONFIG_BARを要求している場合、そっちも勝手に有効化してくれたら嬉しいです。 ですが実際には、mにするかyにするか、或いは複数の OR 条件がある場合どれを満たすべきか、など自由度が高めなので、全自動にはできそうにありません。あと、依存関係を取得するには Kconfig を読むことになるので、シェルスクリプトだと荷が重いかもしれません。 不可能ではないでしょうが、私なら別の言語を使います。
10年前から同じこと言ってる……
NO nop_thread さんが約5時間前に更新 · 編集済み
正直 Kconfig パーサを書くのはちょっとダルいし制約の解決をやるのはもっとダルいので (言うてその辺の SAT/SMT solver とかに丸投げすれば済みそうな話ではあるが (いやこれはかなり怪しい、 =y と =m が両方可能なら =m を優先したいといった preference があるため))、一旦はパッケージ内に hint として制約の解決方法を書いておけば良いのではなかろうか。
たとえば次のような感じで。
[hints]
BAR = ">=FOO"
QUUX = "!bool(BAZ)"
NO nop_thread さんが約4時間前に更新 · 編集済み
nop_thread さんは #note-2 で書きました:
=y と =m が両方可能なら =m を優先したいといった preference があるため
preference 以外にも、「FOO=m のために BAR OR BAZ を満たす必要はあるが、片方だけで良く、しかもどちらでも良い」などの場合に勝手に決めてほしくないというのもあった。
これは非決定性の入り込む余地を減らしたいというだけでなく、たとえばデフォルトで BAR=y を選択していたのに新規追加した QUX=y のために BAZ=y が要求されるようになって BAR=n に変化したなどといったような、予期せぬ機能の無効化を防ぎたいなどの理由もある。
まあ無効化されて困るなら有効化を明示しろという話ではあるのだが、とはいえ一方で書かずに済むものは書きたくないという動機が根底にあるので、曖昧さがないなら勝手に有効化してほしく、曖昧さがある場合のみ明示的な記述を要請してほしいというのが丁度良い落とし所ということになる。