Efficient data transfer through zero copyIBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
Video for Linux Two API Specification
Bill DirksHans VerkuilMartin RubliCopyright © 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin Rubli This document is copyrighted © 1999-2008 by Bill Dirks, Michael H. Schimek, Hans Verkuil and Martin Rubli.Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Versi
ソースコードを読むための技術
$Id: readingcode.html,v 1.13 2003/12/06 00:01:08 aamine Exp $ 2006-05-02 gonzui 追加。thanks: 冨山さん 2003-12-03 ltrace と sotrace を追加 2003-12-03 ツールのところに DDD を追加。thanks: 和田さん 2003-05-27 VCG, SXT などについて追加。thanks: 梅沢さん 2003-05-27 これもすっかり忘れていた strace, ktrace, truss, etags などについて追加 2002-08-30 すっかり忘れていた ctags を追加 2002-07-07 匿名希望さんからメールでいただいた情報を追加 (動的コールグラフ) 2002-06-13 日記経由でいただいた意見をもとに文章を追加。thanks: 柳川さん、まつもとさ
ひげぽん OSとか作っちゃうかMona- - Emacs + GLOBALでソース読みを快適に
ネットワークサーバー実装のためにuIPのソースを読もう。 NICドライバの移植のためにFreeBSDのソースを読もう。 ということで以前使っていた etags を使おうと思ったがキーバインド忘れた。 そして etags はなんだかいろいろ不満点があった気がするので GLOBALを使ってみることに。 以前GLOBALは出力をHTMLにして使ったことがあるのだが、最近EmacsにどっぷりなのでEmacsから使ってみることに。 0.GLOBALって何? GNU GLOBAL は、ソースコードに索引付けを行うことで、大規模システムのハックやレビューを効率化するソフトウエアです。 ソースファイル中の指定したシンボルを高速に見つけ出し、素早くその場所に移動することができます。多くのサブディレクトリからなり、#ifdef や main() 関数を沢山含んでいるような、いわゆる巨大なプロジェクトをハックす
第1回 ソースコードを読む理由(わけ) | gihyo.jp
はじめまして、Plamo Linux というマイナーな Linux ディストリビューションの取りまとめ役をやっているこじまと申します。これからしばらく「ソースコード・リテラシーのススメ」というタイトルで、オープンソースソフトウェア(OSS)のさまざまなドキュメントやソースコードの読み方について紹介していこうと思っています。 OSSとソースコード・リテラシー 「ソースコード・リテラシー」とは、「メディア・リテラシー」や「コンピュータ・リテラシー」に習った造語で、あからじめ用意されたバイナリパッケージをインストールして使うだけではなく、ソースコードや付属している各種のドキュメントを読んで、それぞれのソフトウェアをより深く理解していく能力を意味しているつもりです。 最近ではLinuxに関するさまざまな情報が雑誌やインターネット上に溢れ、Google等で検索すれば数千、数万ページがヒットするこ
ユメのチカラ: プロセスプログラミングの実践方法
学ぶ方法を学ぶことは重要だ。知識は陳腐化する。しかし、学ぶ方法というのは、道具立てが変わってもかなり安定的で変化は少ない。 インターネットのおかげで確かに知識の取得方法は劇的に変化した。量的な変化が質的な変化に転換した。なんでもかんでもインターネットで検索してからことをはじめるという感じになってしまった。あんまりじっくり考える機会がなくなったような気がしないでもない。 かつてプロセスプログラミングと言う概念が流行った。最近ではあんまり言わないがソフトウェア開発の究極の姿だと言われた。ソフトウェアは人が作るのだが（当たり前だけど）、そのプロセスを厳密に記述していければ、つまりコンピュータが理解可能なくらい精密に記述できれば、ソフトウェア作製も自動化できるのではないかというアイデアである。随分荒唐無稽なことを言うとあなたは思うかもしれないがあながち夢物語ではない。 例えば、ソフトウェア開発では
ユメのチカラ: デバッグの話（昔の日記から）
わたしは、90年代にシリコンバレーにいたとき、シリコンバレー日記と言うものを書いていてWebで公開していた。今そのサイトはないのであるが、インターネットのWebアーカイブにその内容が残っている。先日「プロセスプログラミングの実践方法」というエントリでデバッグの話を書いたので、それつながりということで、当時、記した日記を全文転載し、ちょっと長くなるが後書き的な解説を加えたい。文体が微妙に違うがご愛嬌と言うことでご勘弁願いたい。 転載始まりデバッグ 誰もが使っている言葉なんだけど，実のところよく分からない言葉というのがある．少なくとも，なんとなくの定義はあるのだけど厳密な全員が納得できるような定義があるようでない言葉というのがある． デバッグというのも実はわかったようでいてよく分からない．とりあえづ，デバッグというのはプログラムのバグを直す作業だとしよう．そうするとプログラムのバグとは何か？と
ユメのチカラ: gdbの実践的使い方
「大規模ソフトウェアの効率的な理解(その1、2、3、4、5、6)」などという大袈裟なタイトルでブログを書いたが、今回は一気に実践編ということでフリーソフトウェア定番のデバッガ gdb の実践的使い方について記す。 プログラマの日々には、プログラムを書くためのエディタ、プログラムをコンパイル(あるいは実行)するためのコンパイラ(あるいはインタプリタ)、そしてプログラムを理解するためのデバッガという三種の神器が必須である。 この定番はわたしの場合xemacs/gcc/gdbである。前々職(DECという会社に務めていた)の場合、それぞれプロプライアトリな物を使っていたので微妙に異なるがやることは一緒である。 gdbは何のために利用するかというと、プログラムを理解するために利用する。デバッガなんだからデバッグのために利用するというのは、gdbの底力の半分も利用していないと言ってさしつかえない。 g
ユメのチカラ: 大規模ソフトウェアの効率的な理解（その5）
動的理解、静的理解 ソフトウェアの理解のもう一つの視点は、ソフトウェアの動的な理解と静的な理解というのがある。 動的というのはソフトウェアを実行した時の挙動のことをさし、静的というのはソフトウェア(プログラム)の字面をさす。 静的な側面からの理解はソフトウェアのコードを読み、そこから何らかの形でプログラムの挙動を理解していくというアプローチになる。字面からの理解ということで、ディレクトリ構造やファイル名や変数の命名規則、コードリファレンスなどが静的な理解の対象になる。 動的な理解は、デバッガによる実行、プロファイラ、トレーサー、ベンチマーク、リグレッションテスト等々実行結果による理解となる。各種ツールが理解を支援してくれる。 ソフトウェアというものは、単純化すれば、ある入力に対して何らかの出力をする機械ととらえれば、ソフトウェアを理解するという事は、その入出力の組を知ることに他ならない。動
ユメのチカラ: 大規模ソフトウェアの効率的な理解（その4）
巨視的、微視的な理解 大規模ソフトウェアを理解する視点として、巨視的な理解、微視的な理解というのがある。巨視的な理解では、ソフトウェアをトップダウンに全体像から細部へと理解の道筋をたどる。一方、微視的な理解では、逆に細部から全体像へとボトムアップな理解の道筋をとおる。 規模の理解というのは、典型的な巨視的な理解の手法であり、ソースコードの解析は微視的な手法である。どちらも重要な視点で、それぞれの手法をバランスよく利用する必要がある。 大規模ソフトウェアの場合、微視的な視点からスタートすると、その規模のため、時間がおそろしくかかるという特徴があるので、最初は、巨視的な理解からはじめるのが王道である。その理解のプロセスの中で、興味のあるサブコンポーネント(論理的あるいは物理的な部分)へ到達したとして、そのサブコンポーネントの理解は徹底的に微視的な視点からはいるという方法もある。 例えば、あるソ
ユメのチカラ: 大規模ソフトウェアの効率的な理解（その3）
規模の把握 大規模ソフトウェアの理解はいろいろな観点からのアプローチがある。ソースコード一式(通常tarballと呼ばれている)を入手し、適当なディレクトリに展開する事からはじまる。tarballではなく、CVSのようなソース管理システムから直接入手する場合もある。 tar.gzというような形式の場合、$ tar xvzf XXXX.tar.gz というようなコマンドで展開する。$ cd XXXX してざっとディレクトリをながめる。通常、READMEないしINSTALLなどのファイルがあるので最初にそれを良く読む。またDocsなどというドキュメントを置いておく場所があれば、その中になにがあるかをざっと見る。 いきなりソースコードを変更するのではなく、このようにディレクトリ構造を調べたり、規模の把握をしたり、おおまかな骨格を理解するようにする。ディレクトリ構造は当該ソフトウェアの物理的構造を
ユメのチカラ: ソースコードの読み方
ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。 ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか？ 閑話休題。 ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようにな
Xen Project Source Repositories
Xen Source Repositories Welcome to xenbits — the Xen Project source and distribution server. You probably want to go to the download system to find links to the various Xen packages available. You can also find downloads of archived projects, logos, mascots and other resources on downloads.xenproject.org. Xen Hypervisor Source Reporitories As of February 2013 Xen's source code is maintained using
lguest
Lguest: The Simple x86 Hypervisor Lguest allows you to run multiple copies of the same 32-bit kernel: simply modprobe lg, then run Documentation/lguest/lguest to create a new guest. I suggest you try this yourself - lguest is incredibly easy to get up and running. It's also quite useful: I can test-boot kernels with it in less than a second, or about 10x faster than basic qemu, and 100x faster tha
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログ | 無料ブログを作成しよう
nesugi.net/diary(2007-01-25)
LXR linux/arch/
http://www.eecs.umich.edu/virtual/software.html
Xen Community