タグ

Kernelに関するyukimori_726のブックマーク (244)

  • 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

    Kernel CI: Linux Kernel Testing at kernelci.org - BayLibre
  • 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

    libprocps programming - Qiita
  • ext4のnobarrierとjournal_async_commitの詳細 - Qiita

    はじめに 先の記事の予告の通り、nobarrierとjournal_async_commitがどう動くのかについての詳細の調査を実施した。 なお、ほやほやのLinux-4.10くらいを見ています。 Documentation kernel/Documentation/filesystems/ext4.txtより 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 o

    ext4のnobarrierとjournal_async_commitの詳細 - Qiita
  • I/OスケジューラのCFQとクラスを理解する - Qiita

    はじめに POSIXのタスクのスケジューリングポリシーに類似させて作られたLinux独自のI/Oスケジューリングクラスについての理解を深めようという趣旨の雑記です。なお、Linux-4.10くらいとutil-linux-2.29.2くらいを見ています。 概要 Linuxはタスク(スレッド)ごとにioprio値(io_context)を持つ。これはクラスとデータを組み合わせた値となっている。クラスは下記の4つ。 IOPRIO_CLASS_NONE IOPRIO_CLASS_RT IOPRIO_CLASS_BE IOPRIO_CLASS_IDLE IOPRIO_CLASS_RTとIOPRIO_CLASS_BEの時はさらに0から7までの優先度をデータとして持つ。ioprioはこれらを下記のようなマクロで組み合わせて表示される。kernel/include/linux/ioprio.hより、 10

    I/OスケジューラのCFQとクラスを理解する - Qiita
  • kernel-headersとkernel-devel - Qiita

    概要 kernel-headersとkernel-develを簡単に調べてみたので自分めも。 まず とあるCentOS6.8の初期minimalインストール後 # rpm -qa | grep kernel dracut-kernel-004-409.el6_8.2.noarch kernel-2.6.32-642.15.1.el6.x86_64 kernel-headers-2.6.32-642.15.1.el6.x86_64 kernel-firmware-2.6.32-642.15.1.el6.noarch kernel-2.6.32-642.el6.x86_64 $ rpm -qi kernel-headers ・ ・ Description : Kernel-headers includes the C header files that specify the interfac

    kernel-headersとkernel-devel - Qiita
  • 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

    cgroupのv1とv2の切り分け的なところ - φ(・・*)ゞ ウーン カーネルとか弄ったりのメモ
  • OSカーネルを0から作り始めてみた - Qiita

    1. 概要 OSカーネル[^1]をフルスクラッチで(0から)作り始めてみました。 稿では下記について記載します。 カーネルを自作し始めた背景 カーネル自作における方針 稿執筆時カーネルの機能概要 カーネルの実行方法 プロセスを起動してみる 今後の課題 2. 背景 私がカーネルを自作し始めた理由は次の2点です。 1.コンピュータがどの様に動いてるのか知りたかった 2.使用しているOSに不満があった 2.1 コンピュータがどの様に動いてるのか知りたかった かれこれ10年以上前に遡りますが、私が大学に入学した頃、VisualBasicやBasic、Cなどの言語を使って簡単なソフトウェアを作ることが出来ましたが、どうして簡単なコードでウィンドウが表示できるのか、どうしてprintf文を書けばコンソールに文字が出力できるのか、コンピュータはいったいどんな風に動いてるのか全く分からず、不思議で仕方

    OSカーネルを0から作り始めてみた - Qiita
  • 【技術書典2】Linuxカーネルモジュール自作入門を出します(ダウンロード頒布有) - uchan note

    皆さんは 技術書典2 というイベントをご存知でしょうか。2017年4月9日に秋葉原で開催される、技術書オンリーの同人誌即売会です。 この記事では、技術書典2のために書いた 「Linuxカーネルモジュール自作入門」 の目次をご紹介します。最後にダウンロード販売のお知らせもあります。 追記:おかげさまで、技術書典2自体も私たちのブースも非常に盛況でした。ご来場いただいた方々、運営の方々、他サークルの方々、大変ありがとうございました。ダウンロード販売のお知らせを更新しましたので、興味のある方はご確認をお願いします。 販売情報 日時 2017年4月9日(日) 場所 アキバ・スクエア ブース き-09「tech@サイボウズ式」編集部 書名 Linuxカーネルモジュール自作入門 ページ数 36(表紙含む) 目次 第1章「はじめに」より: 書を手にとって頂いてありがとうございます。このLinux

    【技術書典2】Linuxカーネルモジュール自作入門を出します(ダウンロード頒布有) - uchan note
  • 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万行そこそこ(それでも凄いのですが)だった

    linuxカーネルソースの統計情報 - Qiita
  • 科学実験のようにスケジューラの挙動を観測する - Qiita

    はじめに 書の主な対象読者はlinuxを含むOSのプロセススケジューラについて聞いたことがない人や、名前は知っているけど具体的に何をするものかをよく知らない人です。 linux kernelは複数プロセスを同時に動作させる(正確にはさせているように見せかける)ためのプロセススケジューラという機能を持っています。といっても、みなさんがlinuxシステムを使う場合は通常プロセススケジューラを意識しないで済むようになっています。では、あえて意識したい場合、どのような機能なのかを知ってみたい場合はどうすればよいのでしょうか。 kernel機能(ここではプロセススケジューラ)の挙動を明らかにするには、ソースを読む、色々ソース改変しながら動かしてみる1、などが有効です。しかし、ここでは一切ソースを読まずに、ユーザプロセスを使う実験のみによってカーネルの挙動を観測してみます。これは、まるで神様2の作っ

    科学実験のようにスケジューラの挙動を観測する - Qiita
  • チュートリアル – システムコールの書き方 | プログラミング | POSTD

    しばらく前に私は、「 C言語でシェルを書く方法 」というタイトルで、皆さんが日常的に使っているツールの内部動作を理解するのに役立つチュートリアルを書きました。単純なシェルであっても、数例を挙げるだけでも read 、 fork 、 exec 、 wait 、 write それから chdir など多数のシステムコールが呼び出されていました。この探索に続く次なる旅として、今回はLinux環境においてシステムコールがどのように実装されているのかについて学んでいきましょう。 システムコールとは何か システムコールを実装するに当たって、それが何なのかをまずきちんと理解しておきましょう。そう遠くない昔の私がそうでしたが、素直なプログラマならシステムコールをCライブラリで提供されている関数のことだと定義するかもしれません。しかしこれは全く正しくありません。確かにCライブラリに含まれる関数群はシステムコ

    チュートリアル – システムコールの書き方 | プログラミング | POSTD
  • お手軽Linuxカーネル開発/自動テスト - Qiita

    はじめに これはLinux Advent Calendar 2016 14日目の記事です。 記事では、ワンコマンドでお手軽にlinuxカーネル開発/自動テスト環境を構築する方法を紹介します。その後開発、自動テストの流れについてもチュートリアル形式で紹介します。記事ではelkdat(以下、ツール)というツールを使用します。記事の対象読者はバリバリのカーネル開発者だけでなく、自分のカーネルやカーネルモジュールを一度作ってみたかった人、開発には興味がないけれどカーネルのテスト(たとえばカーネルのバグの原因となったコミットを突き止めたい)には興味のある人も含みます。 記事に記載されているコードを実際に試すためには、仮想化機能を持つCPUを搭載したPCにインストールされたUbuntu16.04が必要です。CPUの仮想化機能を持っているどうかは、shellから以下のプログラムを実行すればわか

    お手軽Linuxカーネル開発/自動テスト - Qiita
  • Linux シグナルの基礎

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

    Linux シグナルの基礎
  • カーネルモジュール作成によるlinuxカーネル開発入門 - 第三回 デバッグ用インターフェース - Qiita

    はじめに 記事は第二回の続きです。前回までの記事を既に見ていることが前提です。 今回は、今後凝ったカーネルモジュールを作るにあたって必要になってくる、デバッグに有用なdebugfsというファイルシステムについて学びます。debugfsはカーネルとユーザとの間で簡単に情報をやりとりするためのファイルシステムです。linuxにはprocfs, sysfsという、このような使い方ができる他のファイルシステムもあります。しかし、前者は原則としてプロセスに関連する情報だけを扱うというルールがあること1、および、後者は扱いかたが少々難しい上に1ファイルにつき1つの値しかやりとりできないという制限があることより、おいそれと使えません。 debugfsは通常/sys/kernel/debugというディレクトリ以下にマウントされています。その下のファイルを読み書きすることによって、カーネルの情報をユーザプ

    カーネルモジュール作成によるlinuxカーネル開発入門 - 第三回 デバッグ用インターフェース - Qiita
  • Linuxのユーザプロセスのメモリマップについて - Qiita

    .text, .data, ユーザ空間のスタック .text, .dataの仮想アドレス空間生成はexec()の処理の一環で行われます。 ポイントになるのは、以下do_execveat_common()で呼び出している2つの関数bprm_mm_init()とexec_binprm()です。 /* * sys_execve() executes a new program. */ static int do_execveat_common(int fd, struct filename *filename, struct user_arg_ptr argv, struct user_arg_ptr envp, int flags) { /* 略 */ retval = bprm_mm_init(bprm); if (retval) goto out_unmark; /* 略 */ retva

    Linuxのユーザプロセスのメモリマップについて - Qiita
  • seqファイルシステムについて - Qiita

    はじめに procfsのエントリを作成する処理はカーネルやデバイスドライバのコードによく現れます。その際によく見かけるのは、以下のようにプレフィックスが「seq_」となっている関数名です。 static const struct file_operations proc_schedstat_operations = { .open = schedstat_open, .read = seq_read, .llseek = seq_lseek, .release = seq_release, }; これはseqファイルシステムと呼ばれる仕組みで提供しているI/Fになります。seqファイルシステムとは何でしょうか。 今回いろいろな目的があり、seqファイルシステムについての文書を作成しました。 なお、今回読んだLinuxのソースコードのバージョンは4.9になります。 まずDocumentを読む

    seqファイルシステムについて - Qiita
  • KernelAddressSanitizer (KASan) による Linux のメモリ破壊問題の検出 - Qiita

    この記事は Fujitsu extended Advent Calendar 2016 の 25 日目の記事です。 記事は全て個人の見解です。会社・組織を代表するものではありません。 この記事では Linux カーネルの機能の一つである、KernelAddressSanitizer (KASan) の紹介、および、機能を実際に使った結果を紹介します。 はじめに カーネルやモジュールにおいて、厄介なバグの一つにメモリ破壊があります。メモリ破壊が厄介なのは、破壊されたことはログやメモリダンプ等からわかりますが、破壊したことの証拠が残らないケースが殆どなことです。なので、ひたすらソース解析や、printkやトレースを仕込んでバグを探す・・・という苦行を繰り返す必要があります。 KASan は Linux 4.0 から導入されており、厄介なメモリ破壊につながる以下のバグを検出する手助けをしてくれま

    KernelAddressSanitizer (KASan) による Linux のメモリ破壊問題の検出 - Qiita
  • Linux Kernel 3.0以降について調べてみた - Qiita

    長いので太字で要点 絞るために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)サポート 4.12 USB Type-C support USB Type-Cのサポート Type-Cについて調べるとUSB PD(最大100Wの電力)規格、映像出力用に対応 セキュリティ周り 何を載せるか粒度が人によって大きく異るが 3.11 New O_TMPFILE o

    Linux Kernel 3.0以降について調べてみた - Qiita
  • カーネルモジュール作成によるlinuxカーネル開発入門 - 第二回 一定時間後に処理をする(タイマー) - Qiita

    はじめに 記事は第一回の続きです。前回までの記事を既に見た上で開発環境ができていることを前提としています。 前回書いたコードはモジュールをロードした時とアンロードしたときだけ動いていました。今回は、ある時点から一定時間後に所定の処理をする方法を学びましょう。そのためにカーネル内のタイマー機能を使います。タイマー機能はカーネル内のいたるところで使われています。 今回書くソースはすべてelkdatのソースディレクトリ以下のdev/module/timer以下に配置するものとします。 一番簡単な例 モジュールロードから10秒後にメッセージを出してみましょう。次のようなソースになります。 #include <linux/module.h> #include <linux/timer.h> MODULE_LICENSE("GPL v2"); MODULE_AUTHOR("Satoru Takeuc

    カーネルモジュール作成によるlinuxカーネル開発入門 - 第二回 一定時間後に処理をする(タイマー) - Qiita
  • 書籍情報―Linuxカーネル 「ソースコード」を読み解く