Linuxハッカーを目指す技術者に役立ちそうな技術ドキュメント「Linux internals」の第2部が公開されています(Hacker News)。これは前回紹介した第1部の続編となるドキュメントで、カーネルのセットアップが完了し、アセンブラ言語からC言語のmain関数がよびだされた後、を解説するものとなっています。 具体的には、プロテクトモード、起動パラメーターのzeropageへのコピー、コンソールの初期化、ヒープの初期化、CPUの検証、メモリの検出、キーボードの検出、Querying(様々な情報の取得)などのトピック関して解説されています。 次回第3部は、ビデオモードの設定と、その他プロテクトモードへ移行する前に行う各種準備、プロテクトモードへの移行を解説する予定となっています。
先週、 Hacker News上で興味深い議論が行われました 。テーマは Linux Kernelのコーディングスタイル についてです。 議論の中で私は、 コーディングで垂直方向にそろえるインデントをとるべきか というささやかな聖戦を仕掛けました。私は全面的に賛成です。理由を説明しましょう。 垂直方向にそろえるインデントをとるとは？ 簡単な例を挙げてみます。 int robert_age = 32; int annalouise_age = 25; int bob_age = 250; int dorothy_age = 56; ちょっと見ただけで、「bob_age」がおかしいと分かるでしょう。また、目視であちこち探さなくても、全ての値が整数であることが簡単に確認できます。 この考え方は 一般的に 共有 されているわけではありません。ですので、なぜ 多くの 人たち がこれを有効なスタイルガ
はじめに Docker はコンテナ型仮想化技術を使ってOSレベル仮想化を実現するコンテナ管理ソフトウェアです。類似のコンテナ管理ソフトとしては、Docker の他にも libvirt、 lxc-tools などがありますが、 Docker には以下の大きな特徴があります。 Infrastructure as Code の思想に基づき、コンテナをコード(Dockerfile) で管理できる docker index で、コンテナイメージを手軽に取得、共有できる Docker は上記のような特徴を持つため、アプリケーションのポータビリティを大きく向上させることができると期待されています。 参考：Naoya Ito 氏 "Dockerアプリケーションのポータビリティを考える" 大変便利な Docker ですが、Docker によるコンテナ管理は、実は数多くの Linux Kernel の機能に
前回はPOSIX AIOとLinuxカーネルのAIOサポートについて解説しました。今回は、このAIOの使い勝手を良くするため、POSIX AIOインタフェース準拠のライブラリを作成しています。 LinuxネイティブAIOライブラリliblaioの試作 Linux AIOを使用する場合、現在では前述のlibaioの利用が第一候補になりますが、やや使い勝手が悪いため、本記事でPOSIX AIOインタフェース準拠のライブラリを試作してみます。Linux AIOではO_DIRECTが前提となるため、この点もやや使い勝手が悪いのですが、SSDなどメモリベースのファイルシステムもありますし、動作は非同期になりませんがio_submit(2)はO_DIRECTがなくとも使用可能ですから、まぁ試しにやってみましょう。 ライブラリ設計要点を挙げます。 Linux AIOにPOSIX AIOインタフェースをか
プロセスがブロックする要因の一つにファイルI/Oがあります。これを同期I/Oと言いますが、POSIXではAIO（非同期 I/O、Asynchronous I/O）も定義しており、I/O中でもプロセスがブロックせず他の処理を進められるようになります。 今回は、バッファキャッシュを意識したさまざまなファイルI/Oについて解説します。 メモリマップ I/O ファイルI/Oの一種にメモリマップI/O、mmap(2)があります。mmap(2)（およびmmap2(2)）はオープンされたファイルをプロセスアドレス空間へマッピングするもので、例えばアプリケーション内に領域を用意し、ファイルを読み取る動作は次のようにも実装できます。 3mmap.c 要約 { char a[N]; fd = open(path, O_RDONLY); read(fd, a, N) printf("%.*s\n", N, a)
iostat はどのように %util を算出しているか - ablog http://d.hatena.ne.jp/yohei-a/20130925/1380070554 と続いた iostat から Linux Kernel のブロックレイヤーへの旅は Etsukata blog: iostat -x の出力を Linux Kernel ソースコードから理解する のおかげでほぼ終わりを迎えました。 part_round_stats() では、その延長で、全てのリクエストがキューにいた時間の積算値を表すtime_in_queue と、デバイスがIOリクエストを発行していた時間を表す io_ticks を更新しています。io_ticksには前回のリクエスト完了から、今回のリクエスト完了までを加算し、time_in_queueにはそれに実行中のリクエスト数を掛けたものを加算しているのがわかり
本書には、Linuxの概要、カーネル、Cライブラリ、Cコンパイラなどプログラミングの基礎知識から、ファイルI/O、バッファサイズ管理、メモリマッピング、最適化技術、システムコール、メモリ管理まで、プログラマの観点から実践的なトピックが多く盛り込まれています。Linuxカーネル動作についても、その内部実装よりもプログラマがソースコードを書くために必須の知識が凝縮されています。実践的なプログラミング能力の習得に役立つ一冊です。カーネル2.6対応。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作成し、増刷書籍を印刷した月です。お手持ちの書籍では、すでに修正が施されている場合がありますので、書籍最終ページの奥付でお手持ちの書籍の刷版、刷り年月日をご確認の上、ご利用ください。 1、2刷正誤表
Linux Daily Topics 2010年11月18日"ミラクルパッチ"にLinusも大喜び！Linuxカーネルを高速化させた233行のコード Linus Torvalds氏という人は、少なくともメールの中では、かなりはっきりと感情を表に出す。誰かor何かに対して怒っているときは相手を名指しで批判（というより非難）し、逆にうれしいときはあふれる喜びを隠そうとしない。今回紹介するのは後者のほう。「I'm also very happy」「it is a _huge_ improvement」「Good job.」など、喜びと称賛の表現がたくさん書かれているメールだ。 Linus氏を歓喜させたのは、カーネル開発に携わるMike Galbraith氏が書いた233行のカーネルスケジューリングパッチ。このパッチを適用すると、デスクトップ環境においてパフォーマンスが著しく向上するという。
TOPICS Hacks , Programming , Linux , Ruby 発行年月日 2009年04月 PRINT LENGTH 424 ISBN 978-4-87311-404-0 FORMAT PDF ミラクル・リナックス株式会社の精鋭エンジニアたちが、長年のLinuxカーネル開発の経験で培ったデバッグテクニックを詳解。こころがまえから、準備、必要な知識、バグの原因をすばやく特定し修正するために便利なテクニックとツール、高度なデバッグ技まで惜しみなく披露します。多くの事例に基づいた実際的実用的な技が満載です。効率良くかつクオリティーの高い開発のために必須の一冊です。 Debug Hacks推薦の言葉 プログラムにはバグが付き物です。バグは人間の予想を超えたところからやってきます。世界最初のバグは、リレー式計算機の中にまぎれこんだ蛾だったそうです。あわれリレーの間に挟まれた蛾に
トップページへ Linuxカーネルに関する技術情報を集めていくプロジェクトです。現在、Linuxカーネル2.6解読室の第2章までを公開中。 目次まえがき第0章 Linuxカーネルの構成要素 0.1 Linuxカーネルとは 0.2 Linuxカーネルのソースコード 0.3 Linuxカーネル機能の概要 0.4 カーネルプリミティブ 0.5 プロセス管理 0.6 メモリ管理 0.7 ファイルシステム 0.8 ネットワーク 0.9 プロセス間通信 0.10 Linuxカーネルの起動 0.11 Linuxカーネルの動作例 Part 1 カーネルプリミティブ第1章 プロセススケジューリング 1.1 マルチタスク 1.2 プロセスとは？ 1.3 プロセス切り替え 1.4 プロセスディスパッチャの実装 1.5 プロセススケジューラ 1.6 プロセススケジューラの実装 1.7 事象の待ち合わせ 1.8 最
サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第2回（毎週火曜日に掲載、これまでの連載一覧）。「WEB+DB PRESS Vol.80」（2014年4月24日発売）に執筆した「エンジニアの学び方──効率的に知識を得て，成果に結び付ける」の続編です。（編集部） 文：西尾 泰和 イラスト：歌工房 この連載では「エンジニアの学び方」をテーマにインタビューを行い、どういう「学び方」をしているのか探求していきたいと思っています。第1弾は、富士通のエンジニアとしてLinuxカーネルの開発に参加されている小崎資広さんです。 Linuxカーネルは、ソースファイルだけで3万5000個以上、行数にして1500万行を超える、巨大ソフトウェアです。小崎さんが、どうやってこの巨大なソースコードと戦っているかは、きっと「エンジニアの学び方」の参考になるはずです。
Linus Torvalds、 GCC 4.9.0のコード生成にブチ切れる
Phoronixで知ったが、Linus TorvaldsがGCC 4.9.0のコード生成にブチ切れている。 問題はLinuxカーネルのload_balance()がランダムにパニックを起こすというもので、その原因は、報告者の使っているコンパイラーであるGCC 4.9.0のコード生成がおかしかったという話だ。 Linus様は御自ら生成されたコードを読み給い、平生と変わらぬ調子で物事の道理を示された。 Linux-Kernel Archive: Re: Random panic in load_balance() with 3.16-rc From: Linus Torvalds Date: Thu Jul 24 2014 - 14:47:25 EST On Wed, Jul 23, 2014 at 6:43 PM, Michel DÃnzer <michel@xxxxxxxxxxx> wro
Linuxカーネルに興味があるんだけど特に作りたいものってないんだよなーなんて割とあると思う訳です。俺とか。。。 まあ、kernelnewbiesのメーリングリストでもよく見る話題かと思います。この辺なんかもそうですね。 で、そんな時にオススメできるのがkmemleak。カーネルに組み込まれたメモリーリーク検出ツールです。 使い方は至って簡単でカーネルのコンフィグレーションにあるKernel memory leak detectorを有効にしたカーネルを普通に使えばOK。カーネルはメインラインのrcでもtipでもlinux-nextでも何でも良いと思います。 設定の場所はKernel Hacking -> Memory Debugging -> Kernel memory leak detectorにチェックをするのと、 その下のMaximum kmemleak early log ent
@ITに以下のような記事が出て、 今回からしばらくの間は、まったく逆の例、つまり使うとプログラムの処理性能が上がるというシステムコールを紹介していく。システムコールを呼ぶ回数は少ない方が処理性能は高くなるという原則は変わらないが、呼び出しておくと処理性能が向上するシステムコールというものが存在するのだ。こうしたシステムコールを使わないでいることは、とてももったいない。 今回紹介するシステムコールは「mmap(2)」だ。ここでは詳しく仕組みを解説しないが、mmap(2)は、プログラムの処理性能に必ず良い影響を与える。 やはりあった？ 高速化に効くシステムコール (1/2)：知ってトクするシステムコール（3） - ＠IT それを真に受けたのか、「Go言語でmmapシステムコールを使ったファイル読み込みの高速化検討とC言語のコンパイラの話 - ryochack.blog」のようなブログエントリも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
