Kernel CI: Linux Kernel Testing at kernelci.org - BayLibre
The kernelci.org project aims to improve the quality of the mainline Linux kernel by improving testing and validation across the wide variety of diverse hardware platforms that run Linux. There are so many different devices and platforms that run Linux, and Linux kernel development is moving so quickly that it is difficult to ensure that any given platform will remain working and stable with each
libprocps programming - Qiita
#include <stdio.h> #include <proc/readproc.h> static void show_proc(proc_t *proc_info) { printf ("tid=%d, ppid=%d, pgrp=%d, session=%d, tty=%d, tpgid=%d [%s]\n", proc_info->tid, proc_info->ppid,proc_info->pgrp, proc_info->session, proc_info->tty, proc_info->tpgid, proc_info->cmd); return; } int main(int argc, char* argv[]){ PROCTAB* proc; proc_t *proc_info; proc = openproc(PROC_FILLARG | PROC_FILL
ext4のnobarrierとjournal_async_commitの詳細 - Qiita
185 barrier=<0|1(*)> This enables/disables the use of write barriers in 186 barrier(*) the jbd code. barrier=0 disables, barrier=1 enables. 187 nobarrier This also requires an IO stack which can support 188 barriers, and if jbd gets an error on a barrier 189 write, it will disable again with a warning. 190 Write barriers enforce proper on-disk ordering 191 of journal commits, making volatile disk
I/OスケジューラのCFQとクラスを理解する - Qiita
IOPRIO_CLASS_NONEを指定しようとした時は、優先度を入れようとしていないことを確認して0にしているくらいで、特にIOPRIO_CLASS_BEに倒したりエラーにしたりはしていない。後にもいろいろ関連すること記述するが、少なくともionice(1)を見る限り、IOPRIO_CLASS_NONEという種類のクラスがあると考えた方がよい。 I/Oスケジューラの種類 LinuxではブロックデバイスごとにI/Oスケジューラを設定できる。動的に変更することもできる。どれになるかは下記の順で決まる。 /sys/block/sda1/queue/schedulerに値を書く (詳細はググればたくさん見つかるのでそちらに任せる) cmdlineに elevator=cfqなどを足す コンパイルオプション**CONFIG_DEFAULT_IOSCHED="cfq"**などを足す 一般的な環境だと
kernel-headersとkernel-devel - Qiita
$ rpm -qi kernel-headers ・ ・ Description : Kernel-headers includes the C header files that specify the interface between the Linux kernel and userspace libraries and programs. The header files define structures and constants that are needed for building most standard programs and are also needed for rebuilding the glibc package. $ rpm -ql kernel-headers | more /usr/include/asm /usr/include/asm-gen
cgroupのv1とv2の切り分け的なところ - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
cgroupはv1とv2という2つの実装（と言っていいのか？）があってそれらはkernel/cgroup.cで一つのコードベースにまとまっているのでコード読んでで混乱するなーというところで、誰得なめもを。 特に、4.1とかのカーネルだとv2のコードはまだ正式版となってないけどマージはされていて、DEVELsane_behaviorというオプションを使うことでv2の機能が使えるようになってます（参考： Linux 3.16 から試せる cgroup の単一階層構造 (1) - TenForward）。今はv2がちゃんと入っているのでこのオプションは不要で、cgroupのマウント時にcgroup v2としてマウントするかどうかで切り分けできます。cgroup_mount()のis_v2がそれです。 2083 static struct dentry *cgroup_mount(struct f
OSカーネルを0から作り始めてみた - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #1. 概要 OSカーネル1をフルスクラッチで（0から）作り始めてみました。 本稿では下記について記載します。 カーネルを自作し始めた背景 カーネル自作における方針 本稿執筆時カーネルの機能概要 カーネルの実行方法 プロセスを起動してみる 今後の課題 #2. 背景 私がカーネルを自作し始めた理由は次の2点です。 1.コンピュータがどの様に動いてるのか知りたかった 2.使用しているOSに不満があった ##2.1 コンピュータがどの様に動いてるのか知りたかった かれこれ10年以上前に遡りますが、私が大学に入学した頃、VisualBasicや
【技術書典2】Linuxカーネルモジュール自作入門を出します（ダウンロード頒布有） - uchan note
皆さんは 技術書典2 というイベントをご存知でしょうか。2017年4月9日に秋葉原で開催される、技術書オンリーの同人誌即売会です。 この記事では、技術書典2のために書いた 「Linuxカーネルモジュール自作入門」 の目次をご紹介します。最後にダウンロード販売のお知らせもあります。 追記：おかげさまで、技術書典2自体も私たちのブースも非常に盛況でした。ご来場いただいた方々、運営の方々、他サークルの方々、大変ありがとうございました。ダウンロード販売のお知らせを更新しましたので、興味のある方はご確認をお願いします。 販売情報 日時 2017年4月9日（日） 場所 アキバ・スクエア ブース き-09「tech＠サイボウズ式」編集部 書名 Linuxカーネルモジュール自作入門 ページ数 36（表紙含む） 目次 第1章「はじめに」より： 本書を手にとって頂いてありがとうございます。この本はLinuxカ
linuxカーネルソースの統計情報 - Qiita
はじめに 本記事はlinuxカーネルのソース分析によって、このソフトウェアの様々な特徴を可視化します。ソースの総行数といったありがちなものから、1つのバージョン内のrelease candidate(rc)ごとのパッチ数の推移やサブシステムごとのデータなども出しています。 linuxには、v2.6.x, v3.x, v4.xで表す、Linuxのオリジナル開発者であるLinus Torvalds氏がリリースするmainlineカーネル(通常、単にLinuxと言えばmainlineカーネルを指す)があります。このうち、データ採取した範囲はgitで追える範囲のv2.6.12〜v4.10までです。ものによってはv4.0〜v4.10までの範囲です。 全体の傾向 総行数 行数は*.[chS]というパターンにマッチする行の数を使いました。v2.6.12では600万行そこそこ(それでも凄いのですが)だった
科学実験のようにスケジューラの挙動を観測する - Qiita
はじめに 本書の主な対象読者はlinuxを含むOSのプロセススケジューラについて聞いたことがない人や、名前は知っているけど具体的に何をするものかをよく知らない人です。 linux kernelは複数プロセスを同時に動作させる(正確にはさせているように見せかける)ためのプロセススケジューラという機能を持っています。といっても、みなさんがlinuxシステムを使う場合は通常プロセススケジューラを意識しないで済むようになっています。では、あえて意識したい場合、どのような機能なのかを知ってみたい場合はどうすればよいのでしょうか。 kernel機能(ここではプロセススケジューラ)の挙動を明らかにするには、ソースを読む、色々ソース改変しながら動かしてみる1、などが有効です。しかし、ここでは一切ソースを読まずに、ユーザプロセスを使う実験のみによってカーネルの挙動を観測してみます。これは、まるで神様2の作っ
チュートリアル – システムコールの書き方 | プログラミング | POSTD
しばらく前に私は、「 C言語でシェルを書く方法 」というタイトルで、皆さんが日常的に使っているツールの内部動作を理解するのに役立つチュートリアルを書きました。単純なシェルであっても、数例を挙げるだけでも read 、 fork 、 exec 、 wait 、 write それから chdir など多数のシステムコールが呼び出されていました。この探索に続く次なる旅として、今回はLinux環境においてシステムコールがどのように実装されているのかについて学んでいきましょう。 システムコールとは何か システムコールを実装するに当たって、それが何なのかをまずきちんと理解しておきましょう。そう遠くない昔の私がそうでしたが、素直なプログラマならシステムコールをCライブラリで提供されている関数のことだと定義するかもしれません。しかしこれは全く正しくありません。確かにCライブラリに含まれる関数群はシステムコ
お手軽Linuxカーネル開発/自動テスト - Qiita
はじめに これはLinux Advent Calendar 2016 14日目の記事です。 本記事では、ワンコマンドでお手軽にlinuxカーネル開発/自動テスト環境を構築する方法を紹介します。その後開発、自動テストの流れについてもチュートリアル形式で紹介します。本記事ではelkdat(以下、本ツール)というツールを使用します。本記事の対象読者はバリバリのカーネル開発者だけでなく、自分のカーネルやカーネルモジュールを一度作ってみたかった人、開発には興味がないけれどカーネルのテスト(たとえばカーネルのバグの原因となったコミットを突き止めたい)には興味のある人も含みます。 本記事に記載されているコードを実際に試すためには、仮想化機能を持つCPUを搭載したPCにインストールされたUbuntu16.04が必要です。CPUの仮想化機能を持っているどうかは、shellから以下のプログラムを実行すればわか
Linux シグナルの基礎
TLPI (The Linux Programming Interface) 再々。 TLPI の輪読の際に @matsumotory よりシグナルセットあたりをまとめるようにと指令が出たので、拙遅な感じでまとめました。 シグナルとは プロセス間通信の一種。「プロセスにシグナルを送信すると、そのプロセスの正常処理に割り込んで、シグナル固有の処理(シグナルハンドラ) が実行される」プロセス側では、シグナルを受信した際の動作(シグナルハンドラ) を設定することや、シグナルをブロックすることも可能。 コンソールで、プロセスを終了させるためにkill -9 <PID>とかCtrl+Cとかした際にも、対象プロセスにシグナルが送信されている。 ちなみに、PID「1」の init や systemd にkill -9 1しても何も起らない。(そういえば昔、oom-killer に init を殺された覚
カーネルモジュール作成によるlinuxカーネル開発入門 - 第三回 デバッグ用インターフェース - Qiita
はじめに 本記事は第二回の続きです。前回までの記事を既に見ていることが前提です。 今回は、今後凝ったカーネルモジュールを作るにあたって必要になってくる、デバッグに有用なdebugfsというファイルシステムについて学びます。debugfsはカーネルとユーザとの間で簡単に情報をやりとりするためのファイルシステムです。linuxにはprocfs, sysfsという、このような使い方ができる他のファイルシステムもあります。しかし、前者は原則としてプロセスに関連する情報だけを扱うというルールがあること1、および、後者は扱いかたが少々難しい上に1ファイルにつき1つの値しかやりとりできないという制限があることより、おいそれと使えません。 debugfsは通常/sys/kernel/debugというディレクトリ以下にマウントされています。その下のファイルを読み書きすることによって、カーネルの情報をユーザプ
KernelAddressSanitizer (KASan) による Linux のメモリ破壊問題の検出 - Qiita
この記事は Fujitsu extended Advent Calendar 2016 の 25 日目の記事です。 記事は全て個人の見解です。会社・組織を代表するものではありません。 この記事では Linux カーネルの機能の一つである、KernelAddressSanitizer (KASan) の紹介、および、機能を実際に使った結果を紹介します。 はじめに カーネルやモジュールにおいて、厄介なバグの一つにメモリ破壊があります。メモリ破壊が厄介なのは、破壊されたことはログやメモリダンプ等からわかりますが、破壊したことの証拠が残らないケースが殆どなことです。なので、ひたすらソース解析や、printkやトレースを仕込んでバグを探す・・・という苦行を繰り返す必要があります。 KASan は Linux 4.0 から導入されており、厄介なメモリ破壊につながる以下のバグを検出する手助けをしてくれま
Linux Kernel 3.0以降について調べてみた - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 長いので太字で要点 絞るためにGPU、仮想関係は省いてます。 NWが長くなったので分割 http://qiita.com/bringer1092/items/b6cd96a7f7db7121e8a7 I/Oが長くなったので分割 http://qiita.com/bringer1092/items/4a62ec6ab62b896ab611 #ハードウェアサポート ##4.6 USB 3.1 SuperSpeedPlus (10 Gbps) support USB3.1のサポート SuperSpeedPlus (10 Gbps)サポート #
カーネルモジュール作成によるlinuxカーネル開発入門 - 第二回 一定時間後に処理をする(タイマー) - Qiita
はじめに 本記事は第一回の続きです。前回までの記事を既に見た上で開発環境ができていることを前提としています。 前回書いたコードはモジュールをロードした時とアンロードしたときだけ動いていました。今回は、ある時点から一定時間後に所定の処理をする方法を学びましょう。そのためにカーネル内のタイマー機能を使います。タイマー機能はカーネル内のいたるところで使われています。 今回書くソースはすべてelkdatのソースディレクトリ以下のdev/module/timer以下に配置するものとします。 一番簡単な例 モジュールロードから10秒後にメッセージを出してみましょう。次のようなソースになります。 #include <linux/module.h> #include <linux/timer.h> MODULE_LICENSE("GPL v2"); MODULE_AUTHOR("Satoru Takeuc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linuxのユーザプロセスのメモリマップについて - Qiita
seqファイルシステムについて - Qiita
書籍情報―Linuxカーネル 「ソースコード」を読み解く