daily dayflower

2009-07-24

USBRH driver for Linux を CentOS 5 で使う

いままで USB-RH を利用してきました*1が,ユーザランドのコマンド(no title)をバックエンドとして使ってきました。

しかし,定期的に情報収集するのならカーネルモジュールである no title を使いたいものです。

メリット
  • カーネルモードで実行されるので効率がよい,可能性がある*2
  • LED やヒータの制御にも対応している(root 権限が必要ですが)
デメリット

では,ということで CentOSビルドしてインストールしてみましたが,うまく動きません。

トラブルシューティングの「USBRH ドライバではなく USB HID ドライバがロードされてしまっている」にバッチリあてはまっています。

dmesg の様子を見てみると,

...... snip snip snip ......

usbcore: registered new driver usbfs
usbcore: registered new driver hub

...... snip snip snip ......

usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver

...... snip snip snip ......

Initializing USB Mass Storage driver...

...... snip snip snip ......

usb 3-1: configuration #1 chosen from 1 choice
hiddev96: USB HID v1.00 Device [Strawberry Linux Co.,Ltd. Hygrometer/Thermometer
] on usb-0000:00:1d.1-1

...... snip snip snip ......

usbcore: registered new driver usb-storage
USB Mass Storage support registered.

...... snip snip snip ......

usbcore: registered new driver usbrh

...... snip snip snip ......

このように,usbrh ドライバがロードされるのは,hiddev や usbhid などのドライバが登録されたあとです。なので USB-RH を usbhid が先に握ってしまい,usbrh ドライバまでまわってこないんですね。

上記トラブルシューティングで usbhid ドライバを一度アンロードしてからロードする,というのは,usb サブクラスドライバドライバチェーンの順序を変えることで(usbrh のほうが usbhid より先に登録されるようにする)USB-RH が接続されている場合に usbrh ドライバが優先的にアタッチすることを期待している,のでしょう。


しかしながら,CentOS では usbhid ドライバは動的カーネルモジュールとしてではなく,静的にカーネルに組み込まれているため,このようなハックは実行しようがありません。


カーネルをリビルドするか……でもこれだけのためにするのもいやだな……と思いながらカーネルソースを覗いてみる*3と,usb 系のモジュールにはアンバインド・バインド処理を行う関数も登録されています。

これうまく使えるといいなぁ……と思いながらウェブで調べると,その答えとなる手法が載っているページがありました。⇒no title

USBデバイス/sys/bus/usb/devices/ ディレクトリ以下に列挙されています。

$ ls /sys/bus/usb/devices/
1-0:1.0  2-2    2-2.1:1.0  2-2:1.0  3-1      4-0:1.0  usb1  usb3  usb5
2-0:1.0  2-2.1  2-2.1:1.1  3-0:1.0  3-1:1.0  5-0:1.0  usb2  usb4

いっぽう,USB サブクラスドライバインタフェース/sys/bus/usb/drivers/ 以下に存在します。

$ ls -F /sys/bus/usb/drivers/
hiddev/  hub/  usb/  usb-storage/  usbfs/  usbhid/  usbrh/

さらに奥底を覗いてみると……

$ ls -F /sys/bus/usb/drivers/usbhid/

2-2.1:1.0@  2-2.1:1.1@  bind  new_id  unbind

まさに,bindunbind などのあやしげな名前のファイルが存在するではないですか。

で,先ほどのページの内容によると,デバイス番号をこれらの疑似ファイルに書き込んでやると,デバイスドライバへのバインド・アンバインドができる,そうなのです。


じっさいにやってみましょう。とりあえず,USB-RH の USB デバイス番号が 3-1:1.0 だとします(デバイスを抜き差しして調べてみてください)。

root 権限で,まずは hiddev ドライバからアンバインドしてみます。

# echo -n "3-1:1.0" > /sys/bus/usb/drivers/hiddev/unbind
echo: write error: no such device

いきなり怒られてしまいました。CentOS では hiddev ドライバは利用されていないのかな。

では,usbhid ドライバからデバイスをアンバインドしてみます。

# echo -n "3-1:1.0" > /sys/bus/usb/drivers/usbhid/unbind

おお,怒られませんでした。ということは usbhid ドライバから切り離せたのかな。

最後に,いよいよ usbrh ドライバにバインドしてみます。

# echo -n "3-1:1.0" > /sys/bus/usb/drivers/usbrh/bind

怒られなかったので,うまくいったと思いたいです。dmesg みてみます。

/home/dayflower/src/usbrh-0.0.7/src/usbrh.c: USBRH device now attached to /dev/usbrh123

おお,無事 usbrh ドライバUSB-RH デバイスを認識しました。

じゃあ proc インタフェースも存在してるかな……

$ ls -F /proc/usbrh/
0/

$ ls -F /proc/usbrh/0/
heater  humidity  led  status  temperature

でてきてる!

$ cat /proc/usbrh/0/status

t:27.67 h:63.30

温湿度もきちんととれてる!


さて,このステップをいかに自動化するか,ですが。

以前も使った udev のしくみを利用します。udev では,デバイスの追加時などに,コマンドを実行することができます。もともと USBRH Linux Driver も modprobe を udev の rules で(/etc/udev/rules.d/10-usbrh.rule)おこなっていますが,これはまず削除しておきます。

んで,たとえば /etc/udev/rules.d/99-usbrh.rules などのファイルに次のように書きます。

ACTION=="add", BUS=="usb", SYSFS{idVendor}=="1774", SYSFS{idProduct}=="1001", \
    RUN+="usbrh.sh '%b:1.0'"

この RUN という部分が,コマンドを実行する部分です。

引数で渡している %b:1.0 というのは %b の部分は $id と同義で,さきほどの 3-1 のようなもので置換されます。後半の :1.0 を決め打ちにしてしまってますが……ここはどうするのがいいんだろう。複数台 USB-RH を接続するとうまくいかないかもしれません。

そして usbrh.sh というのが,さきほどのアンバインド・バインドをおこなうスクリプトで,以下の内容のものを /lib/udev/usbrh.sh という名前*4で置きます。

#!/bin/sh

DRIVER_PATH=/sys/bus/usb/drivers

/sbin/modprobe -v -s usbrh

echo -n "$1" > $DRIVER_PATH/hiddev/unbind 2>/dev/null
echo -n "$1" > $DRIVER_PATH/usbhid/unbind 2>/dev/null
echo -n "$1" > $DRIVER_PATH/usbrh/bind    2>/dev/null

exit 0

これしきの内容であれば普通はわざわざ別スクリプトにする必要もないんですが,udev rules の RUN で指定されたコマンドは,途中で fail するとその後の処理を断念してしまいます。なので,あえて別スクリプトにして戻り値を 0 (成功)にしているのです。

また,2>/dev/null で標準出力を omit してますが,これをはずすとエラーが発生した場合に udev が syslog にエラーを吐きます。んで,実は,なぜか,これらの echo コマンドはすべて,実際には write error: no such device で怒られているのです。ですが,怒られながらも実行すると,きちんと usbrh ドライバにバインドされます。不思議です。


ともかく,これらの仕掛けをして,udevcontrol reload_rules で udev のルールの再読み込みをさせ,USB-RH を抜き差しすると,以後自動的に usbrh ドライバがバインドされるようになります。接続したまま再起動してもきちんと認識してくれました。

おまけの spec ファイル

カーネル RPM モジュールとしてビルドしてみました。

# kmod-usbrh.spec

Source10: kmodtool
%define   kmodtool sh %{SOURCE10}

%{!?kversion: %define kversion %(uname -r)}
# hint: this can be overridden with "--define kversion foo" on rpmbuild, e.g.
# --define "kversion 2.6.18-128.el5"

%define kmod_name usbrh
%define kverrel %(%{kmodtool} verrel %{?kversion} 2>/dev/null)

%define upvar ""

%ifarch i686 x86_64 ia64
%define xenvar xen
%endif

%ifarch i686
%define paevar PAE
%endif

%{!?kvariants: %define kvariants %{?upvar} %{?xenvar} %{?paevar}}
# hint: this can be overridden with "--define kvariants foo" on rpmbuild, e.g.
# --define 'kvariants "" PAE'

Name:           %{kmod_name}-kmod
Version:        0.0.7
Release:        1%{?dist}
Summary:        kernel module for USB hygrometer / thermometer USB-RH
Group:          System Environment/Kernel
License:        GPL
URL:            http://acapulco.dyndns.org/usbrh/
Source0:        http://acapulco.dyndns.org/usbrh/usbrh-%{version}.tgz
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires:  sed
ExclusiveOS:    linux
ExclusiveArch:  %{ix86} x86_64

%description
USB-RH is a hygrometer / thermometer connected via USB.

# magic hidden here:
%{expand:%(%{kmodtool} rpmtemplate_kmp %{kmod_name} %{kverrel} %{kvariants} 2>/dev/null)}
# additional files
%{_sysconfdir}/udev/rules.d/99-kmod-usbrh.rules
%attr(0755,root,root) /lib/udev/usbrh.sh

%prep
%setup -q -c -T -a 0

sed -i -e "/etc\/udev/d" %{kmod_name}-%{version}/Makefile

for kvariant in %{kvariants}; do
    cp -a %{kmod_name}-%{version} _kmod_build_$kvariant
done
cd %{kmod_name}-%{version}

%build
[ -n $RPM_BUILD_ROOT -a "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
mkdir -p %{buildroot}

for kvariant in %{kvariants}; do
    ksrc=%{_usrsrc}/kernels/%{kverrel}${kvariant:+-$kvariant}-%{_target_cpu}
    pushd _kmod_build_$kvariant
    make TOPDIR=${ksrc} all %{?_smp_mflags}
    popd
done

%install
for kvariant in %{kvariants}; do
    ksrc=%{_usrsrc}/kernels/%{kverrel}${kvariant:+-$kvariant}-%{_target_cpu}
    pushd _kmod_build_$kvariant
    make TOPDIR=${ksrc} INSTALL_MOD_PATH=$RPM_BUILD_ROOT INSTALL_MOD_DIR=extra/%{kmod_name} install %{?_smp_mflags}
    popd
done

find $RPM_BUILD_ROOT -type f -name \*.ko -exec strip --strip-debug \{\} \;

mkdir -p $RPM_BUILD_ROOT/etc/udev/rules.d/
rule=$RPM_BUILD_ROOT/etc/udev/rules.d/99-kmod-%{kmod_name}.rules
echo -n 'ACTION=="add", BUS=="usb", '                          >$rule
echo -n 'SYSFS{idVendor}=="1774", SYSFS{idProduct}=="1001", ' >>$rule
echo    "RUN+=\"usbrh.sh '%b:1.0'\""                          >>$rule

mkdir -p $RPM_BUILD_ROOT/lib/udev/
usbrh_sh=$RPM_BUILD_ROOT/lib/udev/usbrh.sh
echo '#!/bin/sh'                                              >$usbrh_sh
echo 'DRIVER_PATH=/sys/bus/usb/drivers'                      >>$usbrh_sh
echo '/sbin/modprobe -v -s usbrh'                            >>$usbrh_sh
echo 'echo -n "$1" > $DRIVER_PATH/hiddev/unbind 2>/dev/null' >>$usbrh_sh
echo 'echo -n "$1" > $DRIVER_PATH/usbhid/unbind 2>/dev/null' >>$usbrh_sh
echo 'echo -n "$1" > $DRIVER_PATH/usbrh/bind    2>/dev/null' >>$usbrh_sh
echo 'exit 0'                                                >>$usbrh_sh
chmod 755 $usbrh_sh

%clean
[ -n $RPM_BUILD_ROOT -a "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT

%changelog
* Fri Jul 24 2009 dayflower - 0.0.7-1
- Initial release

これ使うには /usr/lib/rpm/redhat/kmodtoolSOURCES/ ディレクトリにコピーしておく必要があります(おのおの自分の SRPM に含めておく慣例みたい)。

んで,たとえば i686 なら,

$ rpmbuild -bb --target=i686 --define 'kvariants ""' SPEC/kmod-usbrh.spec

のようにするとカーネルモジュール RPM が生成されます。kvariants の部分を指定しないと,PAEカーネルモジュールなどもビルドしようとするので注意。

*1 USB-RH で遊ぶ - daily dayflower, USB-RH で温湿度を収集しグラフ化(collectd & rrdtool) - daily dayflower

*2:じっさいには,USB プロトコルシーケンスのやりとりのほうが時間的に食うのでそんなに差はないかと思います。しかし,ユーザランドのコマンドであれば温湿度を計測するたびに libusb が USB-RH を見つけるなどの手間が必要になります。カーネルモジュールのほうは,一度アクセスするデバイスが probe 時に定まってしまえばその手間はなくなるので,やはり軽い可能性があります。

*3no title にお世話になりました。すっごい便利!

*4:ここのディレクトリに置くと,絶対パスで書かなくてもアクセスできるのです。もちろん別の場所に置いて絶対パスで指定してもよいですが。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証