<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hwmon on 思いつきそうで思いつかなくていたときに</title><link>https://blog.fuga.jp/tags/hwmon/</link><description>Recent content in Hwmon on 思いつきそうで思いつかなくていたときに</description><generator>Hugo -- gohugo.io</generator><language>ja-jp</language><copyright>Copyright(c) 2022-2025 SATO Daisuke. All rights reserved.</copyright><lastBuildDate>Thu, 30 Jul 2026 00:00:00 +0900</lastBuildDate><atom:link href="https://blog.fuga.jp/tags/hwmon/index.xml" rel="self" type="application/rss+xml"/><item><title>製品が届く前に、ドライバはもうカーネルにいた — 準備を先に済ませたOSSたち（2026/7/30 Linux動向）</title><link>https://blog.fuga.jp/posts/2026-07-30-linux-oss-trend/</link><pubDate>Thu, 30 Jul 2026 00:00:00 +0900</pubDate><guid>https://blog.fuga.jp/posts/2026-07-30-linux-oss-trend/</guid><description>&lt;p&gt;ふつう物事の順番は「まず出す、あとで整える」ですよね。でも今週のOSS界隈は逆で、出す前にコンパイラやドライバといった足場をせっせと組んでいた側の話が目立ちました。GCCにRustフロントエンドを作る地道な作業から、発売前にLinuxカーネルへドライバを送り込んでしまったファンコントローラーまで、5本まとめてお届けします。&lt;/p&gt;
&lt;div class="video-wrapper"&gt;
 &lt;iframe loading="lazy" 
 src="https://www.youtube.com/embed/5rQt_Po7HVM" 
 allowfullscreen 
 title="YouTube Video"
 &gt;
 &lt;/iframe&gt;
&lt;/div&gt;

&lt;h2 id="1-gccrs--gccのrustフロントエンドがlinuxカーネル対応で前進"&gt;&lt;a href="#1-gccrs--gcc%e3%81%aerust%e3%83%95%e3%83%ad%e3%83%b3%e3%83%88%e3%82%a8%e3%83%b3%e3%83%89%e3%81%8clinux%e3%82%ab%e3%83%bc%e3%83%8d%e3%83%ab%e5%af%be%e5%bf%9c%e3%81%a7%e5%89%8d%e9%80%b2" class="header-anchor"&gt;&lt;/a&gt;1. gccrs — GCCのRustフロントエンドがLinuxカーネル対応で前進
&lt;/h2&gt;&lt;p&gt;「rustcが動かないアーキテクチャでもRustを書きたい」。GCCに独立したRustフロントエンドを作るgccrsプロジェクトの動機はここにあります。&lt;a class="link" href="https://noise.getoto.net/2026/07/28/progress-toward-compiling-linux-with-gccrs/" target="_blank" rel="noopener"
 &gt;LWNの記事&lt;/a&gt;によれば、2026年前半はRust for Linuxのカーネルクレート対応に開発リソースを集中投下してきたそうです。&lt;/p&gt;
&lt;p&gt;1月から5月にかけて名前解決の仕組みを刷新（名前解決2.0）、2月にはcfg-strippingを2パス化、3月には&lt;code&gt;compiler_builtins&lt;/code&gt;と&lt;code&gt;builder_error&lt;/code&gt;が0%から100%に到達、6月にはメタデータのexport/importをASTベースへ全面改修しつつGeneric Associated Types（GAT）を完全サポート。地味な積み重ねですが、&lt;a class="link" href="https://raw.githubusercontent.com/Rust-GCC/Reporting/refs/heads/main/2026/2026-06-monthly-report.org" target="_blank" rel="noopener"
 &gt;gccrs 6月月次レポート&lt;/a&gt;によるとRust-for-Linuxの進捗指標は1月の12%から6月末に40%まで上がっています。半年で3倍以上というのは、地道な作業の割になかなかの伸びだと素直に思いました。&lt;/p&gt;
&lt;p&gt;ただ、この40%という数字にはちょっと注意が要ります。「コンパイルを試みられる」段階を示す自己申告指標であって、「カーネルの4割がGCCでビルドできる」わけではありません。同じ月次レポートでも後期名前解決が28%、型チェックが12%とまだボトルネックが残っていて、コンパイルが通ることとバイナリが正しく動くことは別問題です（gccrs がどういう立ち位置のプロジェクトなのかは&lt;a class="link" href="https://rust-for-linux.com/gccrs" target="_blank" rel="noopener"
 &gt;Rust for Linux公式のgccrs説明ページ&lt;/a&gt;にまとまっています）。派手な見出しになりがちな数字ほど、こういう注釈をちゃんと添えたいところです。開発チームは9月のRustConf 2026（モントリオール）での発表を目標に逆算しながら進めているとのこと——あくまで目標であって、発表が確定した話ではありません。&lt;/p&gt;
&lt;h2 id="2-shelly-300--arch-linuxのguiパッケージマネージャがzigで書き直し"&gt;&lt;a href="#2-shelly-300--arch-linux%e3%81%aegui%e3%83%91%e3%83%83%e3%82%b1%e3%83%bc%e3%82%b8%e3%83%9e%e3%83%8d%e3%83%bc%e3%82%b8%e3%83%a3%e3%81%8czig%e3%81%a7%e6%9b%b8%e3%81%8d%e7%9b%b4%e3%81%97" class="header-anchor"&gt;&lt;/a&gt;2. Shelly 3.0.0 — Arch LinuxのGUIパッケージマネージャがZigで書き直し
&lt;/h2&gt;&lt;p&gt;Arch Linux向けGUIパッケージマネージャ「Shelly」が、&lt;a class="link" href="https://9to5linux.com/shelly-3-0-gui-package-manager-for-arch-linux-released-as-a-major-update" target="_blank" rel="noopener"
 &gt;9to5Linuxが伝えたところによると&lt;/a&gt;バージョン3.0.0で大幅刷新されたそうです。従来のC#/.NETランタイム依存を捨て、システムプログラミング言語Zigでフルスクラッチ再実装したとのこと。正直、「ZigでGTK4のGUIアプリをまるごと書き直す」と聞いた瞬間は半信半疑でした。C#/.NETのランタイムオーバーヘッドが課題だったのは分かるにしても、乗り換え先がZigというのはなかなか思い切った選択です。&lt;/p&gt;
&lt;p&gt;技術面では、Arch Linuxのパッケージ管理ライブラリlibalpmやGTK4、libarchive、GPGをネイティブバインディングで直接呼び出す設計に変わったとのこと。新機能としてAUR検索の並列実行、Flatpakリポジトリのバックエンド対応、グリッド表示とリスト表示を切り替えられる新UIが加わっています。起動速度と実行ファイルサイズが大幅に改善されたと報じられていますが、具体的な倍率やサイズの数字までは出てきませんでした。&lt;/p&gt;
&lt;p&gt;というのも、この話題は9to5Linuxの報道1本だけが根拠で、今回GitHubリリースのような一次資料は確認できていません。技術的にはワクワクする話なんですが、裏取りの層が薄い分、鵜呑みにしすぎず「へー、そうなんだ」くらいの温度で聞いておくのがちょうどいいと思います。&lt;/p&gt;
&lt;h2 id="3-freebsd-q2-2026ステータスレポート--ntsyncとrocm移植が進行中"&gt;&lt;a href="#3-freebsd-q2-2026%e3%82%b9%e3%83%86%e3%83%bc%e3%82%bf%e3%82%b9%e3%83%ac%e3%83%9d%e3%83%bc%e3%83%88--ntsync%e3%81%a8rocm%e7%a7%bb%e6%a4%8d%e3%81%8c%e9%80%b2%e8%a1%8c%e4%b8%ad" class="header-anchor"&gt;&lt;/a&gt;3. FreeBSD Q2-2026ステータスレポート — NTSYNCとROCm移植が進行中
&lt;/h2&gt;&lt;p&gt;FreeBSDプロジェクトが公開した2026年第2四半期のステータスレポートには41件のエントリが並びますが、目玉は2つです。&lt;a class="link" href="https://www.freebsd.org/status/report-2026-04-2026-06/" target="_blank" rel="noopener"
 &gt;レポート本文&lt;/a&gt;によると、Konstantin Belousov氏がWindowsの同期プリミティブを扱うNTSYNCドライバを、Linuxのコードを一切流用せずスクラッチで実装しました。&lt;a class="link" href="https://docs.kernel.org/userspace-api/ntsync.html" target="_blank" rel="noopener"
 &gt;Linux公式のNTSYNCドキュメント&lt;/a&gt;で定義されているLinux 7.0-rc3のインターフェースに互換性を持たせており、&lt;code&gt;/dev/ntsync&lt;/code&gt;経由でセマフォ・ミューテックス・イベントの3種を扱えます。ネイティブのFreeBSD ABIと、Linuxバイナリをそのまま動かすための&lt;code&gt;linux_ntsync&lt;/code&gt; shimの両方に対応しているのが芸が細かいところです。&lt;/p&gt;
&lt;p&gt;ちなみにLinux側では、NTSYNCを使ったWineやProtonでDirt 3が110fpsから860fpsへ、Resident Evil 2が26fpsから77fpsへ改善したという報告があります。数字だけ見ると派手ですが、これはあくまでLinux側のNTSYNCで観測された数値であって、FreeBSD実装のベンチマークではありません。FreeBSD版が同じだけ効くかどうかはまだ分からない、というのは正直に書いておきます。&lt;/p&gt;
&lt;p&gt;もうひとつの注目はAMD ROCmの移植です。FoundationインターンのSourojeet Adhikari氏が&lt;a class="link" href="https://github.com/ROCm/ROCm/issues/1913" target="_blank" rel="noopener"
 &gt;ROCmの公式Issue&lt;/a&gt;のもとで作業中で、当面の目標は「ROCmでベクター加算を動かすこと」。地味な目標に聞こえますが、ROCmのスタックはかなり巨大なので、完成までにはまだ時間がかかりそうです。ほかにFramework Laptop対応の更新やIntel Panther LakeのI2C/SMBusサポート、Realtek RTL8159の10GbE動作確認なども含まれていて、この四半期のFreeBSDは地味に忙しかったようです。&lt;/p&gt;
&lt;h2 id="4-wayfire-011--分数スケーリング精度向上と実験的hdr対応"&gt;&lt;a href="#4-wayfire-011--%e5%88%86%e6%95%b0%e3%82%b9%e3%82%b1%e3%83%bc%e3%83%aa%e3%83%b3%e3%82%b0%e7%b2%be%e5%ba%a6%e5%90%91%e4%b8%8a%e3%81%a8%e5%ae%9f%e9%a8%93%e7%9a%84hdr%e5%af%be%e5%bf%9c" class="header-anchor"&gt;&lt;/a&gt;4. Wayfire 0.11 — 分数スケーリング精度向上と実験的HDR対応
&lt;/h2&gt;&lt;p&gt;wlrootsベースのWaylandコンポジター「Wayfire」が0.11をリリースしました。……と、ここで正直に告白すると、リリース日を確定させるのにけっこう手間取りました。日付の記載が7月27日と7月28日で分かれていて、肝心の&lt;a class="link" href="https://wayfire.org/2026/07/24/Wayfire-0-11.html" target="_blank" rel="noopener"
 &gt;公式ブログ&lt;/a&gt;は2026年7月24日付。3つの日付が並んでしまって「どれが本当なんだ」とちょっと混乱しました。無理に一つに決めるくらいなら、「7月下旬」とぼかしておくほうが誠実だと判断しています。&lt;/p&gt;
&lt;p&gt;中身は日付争いとは裏腹に地に足のついた改善ぞろいです。内部のジオメトリ処理を整数から浮動小数点へ切り替えたことで、125%・150%・175%といった分数スケーリング時の丸め誤差が解消され、XWaylandアプリのHiDPI対応も自動で効くようになりました。もうひとつの目玉がHDR出力への初対応です。ただしデフォルトでは無効の実験的機能で、完全なカラーマネージドHDRパスにはVulkanレンダラーが必要だと公式ブログに書かれています。まだ「使える」と無条件には言えない段階ですね。&lt;/p&gt;
&lt;p&gt;per-outputのICCプロファイルやper-surfaceのカラーマネジメントも実装され、新しいWaylandプロトコルも6種類追加されました。&lt;a class="link" href="https://github.com/WayfireWM/wayfire/releases/tag/v0.11.0" target="_blank" rel="noopener"
 &gt;GitHubのリリースページ&lt;/a&gt;には、wf-shellのGTK4移植や再起動不要でプラグインを切り替えられる&lt;code&gt;wayfire-plugin&lt;/code&gt;コマンドの追加も記載されています。開発チームはこれを「1.0前の最後の計画版」と位置づけているようです。2023年にRaspberry Pi OSに採用され、2024年末にはLabwcへ乗り換えられてしまった経緯もあるプロジェクトなので、この地道な仕上げっぷりには勝手に肩入れしたくなります。&lt;/p&gt;
&lt;h2 id="5-arctic-fan-controller--発売前にlinuxカーネルへドライバを寄贈済み"&gt;&lt;a href="#5-arctic-fan-controller--%e7%99%ba%e5%a3%b2%e5%89%8d%e3%81%ablinux%e3%82%ab%e3%83%bc%e3%83%8d%e3%83%ab%e3%81%b8%e3%83%89%e3%83%a9%e3%82%a4%e3%83%90%e3%82%92%e5%af%84%e8%b4%88%e6%b8%88%e3%81%bf" class="header-anchor"&gt;&lt;/a&gt;5. ARCTIC Fan Controller — 発売前にLinuxカーネルへドライバを寄贈済み
&lt;/h2&gt;&lt;p&gt;締めはいちばん気に入っている話です。冷却製品メーカーのARCTICが、10チャンネルUSBファンコントローラー「ACFAN00351A」（$9）を発売するにあたり、自社社員Aureo Serrano de Souza氏がhwmonドライバを書き上げ、&lt;a class="link" href="https://github.com/torvalds/linux/commit/fc2ce3ee106f2d53eb344f5c4963c897bbb21634" target="_blank" rel="noopener"
 &gt;Linuxメインラインへのマージコミット&lt;/a&gt;を経てLinux 7.2に取り込んでから製品を出荷しました。ファンコントローラーのベンダーがここまでやるのは珍しいと思います（「業界初」とまでは言い切れませんが、少なくとも見た記憶がありません）。&lt;/p&gt;
&lt;p&gt;ドライバはUSB Custom HID（VID 0x3904 / PID 0xF001）を採用し、&lt;code&gt;drivers/hwmon/arctic_fan_controller.c&lt;/code&gt;は約300行、変更ファイルは6件・451行追加でGPL-2.0-or-laterで公開されています。sysfsは&lt;code&gt;fan[1-10]_input&lt;/code&gt;（読み取り専用・約1Hz更新）と&lt;code&gt;pwm[1-10]&lt;/code&gt;（0〜255・読み書き可）を提供する標準的なhwmonインターフェースです。デバイス側からINレポートが約1秒ごとに自動送信される一方、PWM変更にはOUTレポートとACK応答（タイムアウト1000ms）が使われます。ただし&lt;code&gt;GET_REPORT&lt;/code&gt;には対応していないため、起動直後の現在PWM値は読み出せず、書き込みが一度発生するまで初期状態は不明という、地味だけど覚えておきたい制約もあります。&lt;/p&gt;
&lt;p&gt;&lt;a class="link" href="https://lore.kernel.org/r/20260508064405.38676-1-aureo.serrano@arctic.de" target="_blank" rel="noopener"
 &gt;パッチ投稿&lt;/a&gt;が2026年5月8日、hwmonメンテナのGuenter Roeck氏によるレビューを経て6月中旬にマージ、そして7月28日に製品発売という3ヶ月スプリントでした。標準hwmonインターフェースなのでlm-sensorsやfancontrolがそのまま使えます。Phoronixのコメント欄やHacker News、Redditでも肯定的な受け止めが多かったようです。到達時期はLinux 7.2以降で、ローリングリリース系のディストリビューションは早く、Ubuntu LTSのような安定系カーネルは反映まで数ヶ月かかることが多いでしょう。$9の製品にここまでやる律儀さ、素直に好きです。&lt;/p&gt;
&lt;h2 id="まとめ"&gt;&lt;a href="#%e3%81%be%e3%81%a8%e3%82%81" class="header-anchor"&gt;&lt;/a&gt;まとめ
&lt;/h2&gt;&lt;p&gt;コンパイラを先に用意する、ドライバを先に用意する。今週の5本は、使う人の手に届く前に自分で足場を整えておく側の話でした。地味な下準備は目立ちませんが、あとで慌てないためのいちばん確実な手だと思います。皆さんは、こういう「先回りの準備」を評価する派ですか、それとも出てから判断する派ですか？&lt;/p&gt;
&lt;h2 id="参考リンク"&gt;&lt;a href="#%e5%8f%82%e8%80%83%e3%83%aa%e3%83%b3%e3%82%af" class="header-anchor"&gt;&lt;/a&gt;参考リンク
&lt;/h2&gt;&lt;ul&gt;
&lt;li&gt;LWN記事ミラー（gccrs進捗詳報） &lt;a class="link" href="https://noise.getoto.net/2026/07/28/progress-toward-compiling-linux-with-gccrs/" target="_blank" rel="noopener"
 &gt;https://noise.getoto.net/2026/07/28/progress-toward-compiling-linux-with-gccrs/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Shelly 3.0.0リリース発表（9to5Linux） &lt;a class="link" href="https://9to5linux.com/shelly-3-0-gui-package-manager-for-arch-linux-released-as-a-major-update" target="_blank" rel="noopener"
 &gt;https://9to5linux.com/shelly-3-0-gui-package-manager-for-arch-linux-released-as-a-major-update&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;FreeBSD Q2 2026ステータスレポート &lt;a class="link" href="https://www.freebsd.org/status/report-2026-04-2026-06/" target="_blank" rel="noopener"
 &gt;https://www.freebsd.org/status/report-2026-04-2026-06/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Wayfire 0.11開発者公式ブログ &lt;a class="link" href="https://wayfire.org/2026/07/24/Wayfire-0-11.html" target="_blank" rel="noopener"
 &gt;https://wayfire.org/2026/07/24/Wayfire-0-11.html&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Linuxメインラインへのhwmonマージコミット &lt;a class="link" href="https://github.com/torvalds/linux/commit/fc2ce3ee106f2d53eb344f5c4963c897bbb21634" target="_blank" rel="noopener"
 &gt;https://github.com/torvalds/linux/commit/fc2ce3ee106f2d53eb344f5c4963c897bbb21634&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;</description></item></channel></rss>