はてなブックマーク

autofs はアクセスするときに自動的にマウントしてくれる機能です。 [前回](/2012/12/nfs-v3-v4-rhelcentosubuntu.html) 説明した NFS と合わせて使用すると大変便利です。 (もちろん autofs は NFS専用ではなくて、ローカルなファイルシステムに対しても使えますが。) 以下では、最初に RHEL/CentOS でのやり方を説明し、最後に Ubuntu でやる場合の差分を簡単にまとめます。 ### RHEL/CentOS編 ### 動作確認は RHEL 6.3 / CentOS 6.3 でやっております。 NFSクライアント側で autofs サービスを起動しておきます。 パッケージ名は autofs ですが、RHEL/CentOSでは多分デフォルトでインストールされていると思います。 $ service autofs status で

### Zynq とは 最近、仕事で Zynq やってます。 Zynq というのは、 Xilinx からリリースされている ARM + FPGA の SoC である。 Xilinx は All Programmable SoC というキャッチフレーズで呼んでたりする。 なお、Altera からは SoC FPGA という同様のものが出ている。 CPU と FPGA を1チップに、というコンセプトは今に始まったことではない。 私の知る限り、 Virtex II のころから PowerPC 内蔵 FPGA はあったし、ソフトコアなら Microblaze もある。 しかしながら、世の中の流れは ARM なわけで、 ARM を採用している時点で裾野は広い。 かくいう私も ARM 以外のアーキはさっぱりわからないので、これは助かる。 しかも SoC としての完成度が高いので、使いこなせればいろいろ

に注目します。これが、これから降りていこうとするトップ階層のディレクトリ達です。 さらに700行目付近に以下のように書いてあります。 core-y        += kernel/ mm/ fs/ ipc/ security/ crypto/ block/ vmlinux-dirs    := $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \ $(core-y) $(core-m) $(drivers-y) $(drivers-m) \ $(net-y) $(net-m) $(libs-y) $(libs-m))) vmlinux-alldirs    := $(sort $(vmlinux-dirs) $(patsubst %/,%,$(filter %/, \ $(init-n) $(init-) \ $(core-n) $(cor

Makefile 中では、 $(MAKE) や $(AWK) など、変数で記述することがよく行われる。

- `${variable:=value}` 変数 `variable` が空でなければ、 `variable` の値を返す。 空なら、 `variable` に `value` を代入し、`value` を返す。 - `${variable=value}` 変数 `variable` が定義済みなら、 `variable` の値を返す。 未定義なら、 `variable` に `value` を代入し、`value` を返す。 - `${variable:-value}` 変数 `variable` が空でなければ、 `variable` の値を返す。 空なら、 `value` を返す。代入処理は行わない。 - `${variable-value}` 変数 `variable` が定義済みなら、 `variable` の値を返す。 未定義なら、 `value` を返す。代入処理は行わない

前回は、LinuxのトップのMakefile の一番外のネスト ifeq ($(skip-makefile),) について説明しました。 その内部にさらにわかりにくい部分があります。 トップのMakefile の400行目付近からは以下のようなコードになっています。

[以前](/2014/01/u-boot-linux-kernel-zynq.html)、2014年1月時点での U-Boot と Linux のメインラインで Zynq を動かす方法を紹介しました。 その後、コード(特に U-Boot)が大きく変わっているので、 2014年4月時点での動かし方を紹介することにします。 使用するのは、 - U-Boot 2014.04 - Linux Kernel 3.14 - Zynq ZC706 ボード です。 その前に、 Zynq のブートシーケンスを復習しておきましょう。 Active Boot (= JTAG ブート以外)は 1. Boot ROM 2. FSBL 3. U-Boot 4. Linux Kernel というのが、Xilinx が公式にサポートしているブートシーケンスで、 [Xilinx Wiki ページ](http://www.w

Linux Kernel の Device Tree 関連の関数をまとめました。 関数名は `of_` で始まり (OF = Open Firmware)、 `drivers/of/` ディレクトリ以下で定義されています。 ### `of_n_addr_cells` (base.c:53) int of_n_addr_cells(struct device_node *np) ノード `np` の一つ上の親から上流に向かって探索し、 `#address-cells` プロパティが見つかるとその値を返す。 見つからない場合は、 `OF_ROOT_NODE_ADDR_CELLS_DEFAULT` を返す。 ### `of_n_size_cells` (base.c:69) int of_n_size_cells(struct device_node *np) ノード `np` の一つ上の親から

Device Tree というのは、ハードウェアの詳細を記述したデータ構造体です。 元々は PowerPC Sybsystem から始まったようなのですが、すでに ARM Linux は DeviceTree 一色になってしまっています。 そのため Device Tree を知らないと、 SoC の移植はおろか、ドライバの開発もできない。 そこで、 Device Tree の初歩についてまとめてみることにします。 ただし、私自身が初心者ですので、難しいことは説明できませんし、間違っている部分もあるかもしれませんが、ご了承ください。 ARM のことしかわかりませんので、 ARM を対象として書くことにします。 ### 何故に DeviceTree か？ ### より Generic な OS を記述するためです。 ハードウェアを差分を吸収するのがドライバの役目なのですが、勘違いしてはいけない

前回から間があきましたが、今回はLinux Makefile のコンパイルオプションについて解析してみた。 Makefile 中でのコンパイルオプションの与え方は Documentation/kbuild/makefiles.txt の 「3.7 Compilation flags」に記載されている。 ざっと読んでみると、 ccflags-y, asflags-y, ldflags-y これが記載されている Makefile で有効。 (EXTRA_CFLAGS, EXTRA_AFLAGS, EXTRA_LDFLAGS も過去互換のためにサポートされているが、非推奨) subdir-ccflags-y, subdir-asflags-y これが記載されているMakefileとそのサブディレクトリで有効。 CFLAGS_$@, AFLAGS_$@ はファイル単位で追加したいオプションを指定す

[以前](/2014/01/zynq-2.html)、U-Boot と Linux をソースからビルドして Zynq 上で動かすには、[Wiki Page](http://www.wiki.xilinx.com/) を読むのがわかりやすいと書きました。 このページを参照しながら、やっている人も多いのではと思います。 Xilinx は GitHub に[ローカルな開発リポジトリ](https://github.com/Xilinx) を持っていて、 Wiki Page もこのリポジトリを使っています。 ここでは、Xilinx のリポジトリではなく、U-Boot と Linux Kernel のメインラインからコードを持ってきて、 Linux をブートさせるやり方を紹介します。 ちょうど、本日(=2014.1.21) U-Boot 2014.01 がリリースされました。 このリリースから Zy

Linux Kernel の Makefile がどういう仕組みになっているのか前から知りたいと思っていました。 O'REILLY の 「GNU Make」 という本の11章に Linux Kernel の makefile について少し解説があります。 もちろん makefile の仕組み全体は説明してないのですが、いくつかの興味深いトピックについて解説されていて、一読の価値があります。 まずはトップの Makefileの大枠から見てみます。 これは O'REILLY 本で解説されています。 トップのMakefileの100行目付近は以下のようになっています。(途中、あんまり関係ない部分は省略しています。) ifeq ($(KBUILD_SRC),) # OK, Make called in directory where kernel src resides # Do we want

オープンソースをダウンロードしてきて、動かしたり、改造したりしているうちに、 バグ修正や、新機能などをコミュニティへフィードバックしたくなってくるかもしれません。 自分は、最近 U-Boot によくパッチを投稿しています。 以下は、U-Boot にパッチを送り始めた時に自分がやった時の一連の流れをまとめておきます。 U-Boot は基本的に、Linux Kernel と同じ開発スタイルを踏襲しているので、それなりに参考になるかと。 ML に参加する たいていは、パッチはメーリングリストに投稿するようになっていると思います。 なので、まずはメーリングリストを購読します。 やり方は、開発のコミュニティのページに書いてあります。 git send-email を使えるようにする これについては、前回、git send-email でまとめておきました。 投稿用のパッチを作る パッチの作り方は、コ

前回記事 [Zynq 入門中](/2013/12/zynq.html) の続きです。 ISE と Vivado を Ubuntu にインストールします。 前回も述べたように、Ubuntu はサポート外なので、そのままでは動かない部分があります。 バージョンによって若干の差があるかもしれないので、ここでは以下のバージョンとします。 - Vivado 2013.2 - ISE 14.6 - Ubuntu 2013.04 64bit ### Vivado のセットアップ #### インストール Xilinx のページから tar をダウンロードして、以下を実行。 $ Xilinx_Vivado_SDK_2013.2_0616_1.tar $ cd Xilinx_Vivado_SDK_2013.2_0616_1 $ sudo ./xsetup 途中のダイアログで Cable Driver をインス

git には send-email というメールを送信するコマンドがあります。 ただし、普通のメールを送信するのに使うというより、パッチを送る用途に使います。 パッチを自分のメーラーに貼りつけて送信してもいいのですが、 メーラーによっては、長い行を勝手に改行してくれたりして、パッチが破壊される可能性もあります。 リポジトリ管理に git を使っているプロジェクトだと、 git format-pach でパッチ生成 ⇒ git send-email で送信 とするのが手順的にも楽です。 オープンソースの開発にコントリビュートするのに必須ですね。 セットアップについてメモ。 git-core を入れただけでは、 git send-email コマンドはまだ入っていないかもしれません。 Ubuntu の場合は # apt-get install git-email でインストールできます。 (他

clone / push / pull の仕方のメモ。 https を使うか ssh を使うかがあるようだ。 ### https ### $ git clone https://github.com/user_account/project_name.git アカウントとパスワードの入力を求められます。 pull, push もできます。 既にあるリポジトリを push するときは git remote add origin https://github.com/user_account/project_name.git git push -u origin master ### ssh 公開鍵暗号の場合 ### $ ssh-keygen -t rsa 秘密鍵 `~/.ssh/id_rsa` および公開鍵 `~/.ssh/id_rsa.pub` が生成される。 `~/.ssh/id_rsa

`/etc/sudoers` の書き方を調べてみた。 一部コマンドを管理ユーザー以外にも開放したい場合があったので。 たとえば、 Ramdisk をいじるときに `mount` と `umount` が必要だったり。 基本的な書式は ユーザー名 ホスト名=(誰として) コマンド名 という風になっている。 例えば、 hoge fugahost=(piyo) /bin/cp というのは ユーザー `hoge` が、ホスト名 `fugahost` 上で、ユーザー `piyo` として `cp` コマンドを実行することを許す、 という意味になる。 ホスト名の部分は具体的にホスト名を指定する使い道はあまりなさそうなので `ALL` にしておけばいいでしょう。 `(誰として)`の部分も、普通は `root` になりたいはず。 上記の例のように `hoge` さんが sudo -u piyo cp fi

インライン関数についてややこしいところをまとめておきます。 結論から言うと、常に `static inline` を使え、ってことになります。 結果だけ知りたい人は以下は読む必要なし。 ### 最初に ### `inline` キーワードは関数callを高速化せよ、という指定であって、`inline` を付けたからといって、本当にインライン展開されるかはわかりません。 実際のところ、最適化オプションをつけていない場合、`inline` を付けても、一切インライン展開してくれません。 最適化オプションによらず、インライン展開を強制させるには `__attribute__((always_inline))` をつけるというやり方があります。 `-O1` オプションをつけた場合、明示的に `inline` がついている場合はなるべくインライン展開しようとするが、`inline`指定がないものにつ

ARM Linux のカーネルのエントリーから、 `start_kernel` 関数にジャンプするまでのコードを読んでみました。 ARM にそこそこ詳しくないと理解しづらいかもしれませんが、 ARM ARM を見ながら根気強く読んでいくと Linux Kernel だけでなく ARM の勉強にもなります。 カーネルのエントリーは `arch/arm/kernel/head.S` にあります。 バージョンによってちょっと違うかもしれないけど、エントリー部分のコードは以下のような感じになっています。 (以下は v2.6.32 のコードです) ENTRY(stext) setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode @ and irqs disabled mrc p15, 0, r9, c0, c0 @ get pro

最近の gcc だとシンボル解決がうまくいかないといかないことがあったので、ちょっと調べました。 次のような 3つのソースファイルがあったとして、ダイナミックリンクで作ってみましょう。 `main.c` int foo(void); int main(void) { return foo() + 1; } `foo.c` int bar(void); int foo(void) { return bar() + 1; } `bar.c` int bar(void) { return 0; } shared object を作るのに必要なのは、コンパイル時に `-fPIC` オプションをつけることと、リンク時に `-shared` オプションをつけることの 2点です。 $ gcc -fPIC -c -o bar.o bar.c $ gcc -shared -o libbar.so bar.o

NFSv4 と Kerberos を組み合わせて、 NFS のセキュリティの弱さをカバーしてみたいと思います。 長いので 2回に分けました。 今回は Kerberos の初期設定の部分までやってみます。 まずは RHEL/CentOS の場合のやり方を説明し、最後に Ubuntu でやる場合の差分情報をまとめておきます。 ### RHEL/CentOS編 ### RHEL 6.3/CentOS 6.3で確認しました。 Kerberos サーバー側は `krb5-server` パッケージをインストールします。 クライアント側については `krb5-workstation` がデフォルトでインストールされているので、特にインストールする必要はないです。 Kerberos サーバーのことを KDC (Key Distribution Center) と言います。 主に設定変更するファイルは3点

Ubuntu でデスクトップをリモート操作します。 動作確認は Ubuntu 12.04 LTS と Ubuntu 13.04 でしました。 「お手軽編」と「ちゃんとする編」を紹介します。 ### お手軽編 ### vino(サーバー) と remmina (クライアント) を使います。 どちらも、たぶんデフォルトで入っていると思うので、インストールするパッケージはなし。 #### サーバー側 #### サーバー側で vino の設定をします。 メニューから「システムツール」 -> 「設定」 -> 「デスクトップの共有」を選びます。 (自分は Unity が好きではないので、 `gnome-session-fallback` を入れている。) 端末から起動する場合は $ vino-preferences と入力すると、設定ダイアログが出てくる。 「他のユーザーが自分のデスクトップを表示でき

[以前](/2012/02/linuxmakefile-4.html)、 `.PHONY:` 指定と `: FORCE` 指定について触れたことがあるのですが、 明らかに両者を使い分けるべきケースがあることに最近気がついた。 まずは、 make の初歩ですが、 PHONY ターゲットからおさらいします。 次のような `clean` ターゲットがあったとする。 clean: $(RM) $(programs) $(objects) もし、カレントディレクトリにたまたま `clean` という名前のファイルが存在すると、 この `clean` は実行してくれません。 $ touch clean $ make clean make: `clean' is up to date. そこで、 .PHONY: clean clean: $(RM) $(programs) $(objects) としてお

NFSv4 と Kerberos を組み合わせることで、NFSのセキュリティとユーザーマッピングの課題を解決してみました。 これまで、自分が NFS を使う際の懸念事項がセキュリティの問題とユーザーマッピングの問題でした。 #### セキュリティについて #### `/etc/exports` でマウントを許可するクライアントを指定することはできるものの、IPアドレスは基本的に自己申告ですから、LAN内にある全てのマシンが信用できるという場合を除いては、かなり危険だと思います。 ある程度規模の大きい LAN につないでいる場合、中には悪い人がいるかもしれません。 例えば、サーバー側が `/etc/exports` に /home 192.168.11.30(rw,sync) と書いて、公開したとします。 他のマシンから $ showmount -e NFS_SERVER_NAME で問い合

NFSのセットアップ手順を簡単にまとめておきます。 NFS v3以前と v4とでポリシーがかなり違うので、それぞれの方法をまとめておきます。 まずは、 RHEL/CentOS でのやり方をメインに説明します。最後に Ubuntu でやる場合の差分情報もまとめておきました。 ### REEL/CentOS 編 #### NFSv3以前の場合 CentOS の場合、nfs-file-server パッケージはデフォルトでインストールされています。 サーバー側の設定は `/etc/exports` に directory client(option,...) client(option,...) ... の形で記述します。 /path/to/dir1 nfs.client.addr(rw,sync) /path/to/dir2 nfs.client.addr(rw,sync) みたいな感じ。 同