はじめに ファミコンミニ自体の権利表記画面や任天堂Webサイトで配布されているOSSソースコードからも分かるように、ファミコンミニの中で動いているのはU-bootで起動されたLinuxです。なので、ファミコンミニを適切に初期化した上で、適切にビルドしたLinuxカーネルを流しこめば、ファミコンミニ上で自前のLinuxを動かせます。U-boot(GPLv2)とLinux(GPLv2)のソースコードを読解・ビルドして自前のLinuxを起動したので、手順を書きます。 ファミコンミニで自前ビルドのLinux動いた (My Linux kernel on NES Classic) pic.twitter.com/00EZZgMx7A — op (@6f70) 2016年11月13日 注意 この記事の内容を実践すると、製品保証が無効になったり、故障に繋がる可能性があります。内容を理解できる人が自己責任

TLPI (The Linux Programming Interface) 再々。 TLPI の輪読の際に @matsumotory よりシグナルセットあたりをまとめるようにと指令が出たので、拙遅な感じでまとめました。 シグナルとは プロセス間通信の一種。「プロセスにシグナルを送信すると、そのプロセスの正常処理に割り込んで、シグナル固有の処理(シグナルハンドラ) が実行される」プロセス側では、シグナルを受信した際の動作(シグナルハンドラ) を設定することや、シグナルをブロックすることも可能。 コンソールで、プロセスを終了させるためにkill -9 <PID>とかCtrl+Cとかした際にも、対象プロセスにシグナルが送信されている。 ちなみに、PID「1」の init や systemd にkill -9 1しても何も起らない。(そういえば昔、oom-killer に init を殺された覚

大人気TBSドラマ、「逃げるは恥だが役に立つ」でも話題になったインフラエンジニアという言葉ですが、今ではインターネットインフラを知らないまま開発をするのも難しい状況になっています。クラウドが一般化されたからといって単にリソースの調達が簡単になっただけで、つまりハードウェアの知識が無くても何とかやっていけるようになっただけであり、インフラの知識が要らなくなったなどということは全くなく、むしろdevopsの掛け声とともに、ソフトウェア開発者にインフラを見なければならない新たな責務が課せられたという、なかなか痺れる状況なのだろうと思います。 そういった中で、先日のさくらインターネットのAdvent Calendar最終日に「いまさら聞けないLinuxとメモリの基礎＆vmstatの詳しい使い方」という記事を書かせて頂きましたが、今回はLinuxサーバの「負荷」と、ロードアベレージに関して、掘り下げ

(2019/6/12追記) 今なおこの記事を参照してくれる方がいらっしゃるのですが、現在は以下のスライドのほうが情報が新しいです。 本記事は残しておきますが、新しい情報はこちらをご参照ください。 https://www.slideshare.net/ygotokernel/nvdimmlinux-137104084 はじめに Linux Advent Calendarの24日目の記事として不揮発メモリの状況について記載したいと思います。今回はkernelのソースの中とかのあまり技術的に深いところは突っ込まず、概略レベルです。（深いところはまだまだ勉強中の身です）。間違いなどがあればご指摘いただけると幸いです。 不揮発メモリとは これまでPCやサーバなどで主記憶装置といえば、電源を停止させたり再起動させるとデータがクリアされる揮発性のRAMが使われて来ました。この主記憶としてのメモリが不揮発

はじめに これは Linux Advent Calendar 2016 の第 11 日目の記事です。Linux のタスクスケジューラーのソースコードや関連するドキュメントなどを読んで分かったことをまとめました。とても長いです・・・ はじめにスケジューラーのアーキテクチャと重要な概念を紹介し、その後はスケジューラーコアとシステムコールの実装について分かったことを延々と述べます。調べきれなかったことや分からなかったことは TODO に残したので、コメント欄とかツイッターで教えてもらえると嬉しいです。間違いの指摘も大歓迎です。 ちなみに私が読み始めたきっかけは、スケジューラーのアーキテクチャ、スケジューリングアルゴリズム、スケジューリングアルゴリズムの切り替え方、nice 値やプロセッサアフィニティがスケジューリングに及ぼす影響、プリエンプションの流れ、マルチプロセッサにおけるタスクのロードバラ

この記事はLinux Advent Calendar 2016 9日目の記事です。 遅刻してしまい申し訳ございません。。。 とある事情があって1ヶ月半ほど独自NICのLinux向けのネットワークドライバを開発していた。 今回はARM用のデバイスドライバを開発した。NICはXilinx社のFPGAであるZYBOを用いて開発した。 まだ十分に実用段階というわけではないが、ひとまず独自NIC経由でのpingやiperfが通ったので、後学のために知見を残しておきたい（誰得だ、という感じだが）。 ソースコードはまだ公開されていないが、そう遠くないうちに公開する予定（たぶん）。 はじめに Linuxのデバイスには キャラクタデバイス - バイト単位のデータ通信 (e.g. シリアルポート) ブロックデバイス - ブロック単位のデータ通信 (e.g. ディスク) ネットワークデバイス の3種類がある。ネ

XFSは、巨大ストレージでの利用を視野に入れた64bitファイルシステムである。膨大な領域を効率的に利用するため、XFSにはさまざまな仕組みが組み込まれている。（編集局）

要約 この記事では、LinuxカーネルにてLinuxプログラムがどのように関数を呼び出すのかについて紹介していきます。 システムコールを行う様々な方法、システムコールを行うための独自のアセンブリの作成方法（例あり）、システムコールへのカーネルエントリポイント、システムコールからのカーネルイグジットポイント、glibcのラッパ関数、バグなど多くの点について説明します。 要約 システムコールとは？ 必要条件に関する情報 ハードウェアとソフトウェア ユーザプログラム、カーネル、CPUの特権レベル 割り込み モデル固有レジスタ（MSR） アセンブリコードでシステムコールを呼び出すことの問題点 レガシーシステムコール 独自のアセンブリを用いたレガシーシステムコールの使用 カーネル側での int $0x80 エントリポイント iret を使用したレガシーシステムコールからの復帰 高速システムコール 3

Linuxカーネルのコードを読んでて、なるほど〜と思うことはよくあるけど、その中でも特に今までの考え方をぶち壊してくれたのはなんだっけと思ったところ、やっぱりリスト構造かなと言うところ。 c言語でリスト構造を作る場合、一般的な教科書方式だと↓のようにデータとnextポインタは密結合になってると思います。これの場合、struct foobarのポインタをnext要素に使っているので、他の構造体（例えば、struct hogehoge）で同じことをしようとすると、その構造体ではstruct hogehoge *nextというメンバ変数を持つ必要があります。 ヘッド要素はstruct foobarです。 struct foobar { int n; char s[64]; struct foobar *next; }; struct foobar head; Linuxカーネルの場合、データとリ

Linus Torvalds / 青木靖 訳 2016年2月 (TED2016) クリス・アンダーソン 奇妙な話です。あなたのソフトウェアであるLinuxは何百万というコンピュータの中にあり、インターネットのかなりの部分を動かしています。さらに実際に使われているAndroid端末が15億台くらいあって、その１台１台にもあなたのソフトウェアが入っています。これはすごいことで、その開発本部ともなれば、さぞ大層な施設なんだろうなと思っていたので、この写真を見たときはびっくりしました。これがその — Linux世界本部なんですよね？(笑)(拍手) リーナス･トーバルズ 大したものには見えませんよね。この写真の中で最も興味深く、多くの人が反応する部分は、あのトレッドミル・デスクです。私の仕事場で一番興味深いものですが、私はもう使っていません。この２つは関連していると思います。私の働き方として、外的な

Kernel Recipes 2017 - Understanding the Linux kernel via ftrace - Steven RostedtAnne Nicolas