Improving LLVM Backend Development with a New TableGen Language Server
Zig Advent Calendar 2022 に参加しています。 あるプログラムを作ろうと思ったのですが、それにはepollとsignalfdのシステムコールを使うのが良さそうだということがわかりました。これらのシステムコールを使うのは初めてだったのでまずは理解のために簡単なサンプルプログラムを作りました。そしてせっかくなのでそれをZig言語で書き直しました。 システムコール epoll について epollはLinuxでのI/Oイベントの通知のしくみです。これを使って複数の入出力を待つことができます。似たものにselectやpollがありますが、epollはそれらの中でも後発で、他のものにあった欠点を解決し柔軟性も性能も高いものになっています。なので、これから新規に作るならばepollを使うのがよいでしょう。なお、Zig言語のライブラリのstd.os.linuxではselectはサポ
WebブラウザでOS動かしてどうすんだよ という根源的な疑問に回答が無いままとりあえずできちゃった。。 ※ コマンドが終了してもプロンプトが出ません。Enterを空打ちする必要があります (バグ) WasmLinuxは、WebAssembly "ネイティブ" なLinux環境です。カーネルもユーザーランドも、WebAssemblyのツールチェインでコンパイルされたWebAssemblyモジュール(をwasm2cでCにしたもの)です。 前回はカーネルしか動いていなかったんですが、今回はブラウザ上で ifconfig lo up して ping 127.0.0.1 したり top したり vi したりできます。BusyBox入ってるので。 ただしまだ実用性は皆無 です。Proof of Conceptって奴ですね。 前回の記事: 今回はMUSL libcを移植してBusyBoxが動くようになっ
Rust を勉強し始めたので冬休みの間に Linux の boot protocol を喋る x86ブートローダー（自称:Krabs）を作ってみました。この記事では、開発に至った動機や、作成した Krabs の特徴とか仕組み、開発中におきた嬉しかったことなどについて書きたいと思います。 Krabs とは Krabs は、Rustで書かれた x86/x86_64(Legacy BIOS) 向けの４段ロケット構成のチェインローダーです。 bzip2 で圧縮された ELF 形式のカーネルを起動できます。bzip2 圧縮されたイメージを解凍して、次に展開してでてきた ELF イメージを再配置してからの、カーネルの起動となります。 内部では libbzip2 の C ライブラリを利用していますが、それ以外は全て Rust で記述されています。 GitHub - o8vm/krabs: An x86
セキュキャン2023でSysmonForLinuxを使った経験があり、プログラムの挙動ログを自作ロガーで取りたいなと思ったので、Go+ebpf-goで簡単なシステムコールロガーを実装した。eBPFもGoも初心者なのでコードが汚いのは御愛嬌。 コード全体 コードはここに書いた。記事作成時点のコードであって、最新版ではないので注意。 main.go package main import ( "bytes" _ "embed" "encoding/binary" "encoding/json" "fmt" "os" "os/signal" "syscall" "github.com/cilium/ebpf" "github.com/cilium/ebpf/link" "github.com/cilium/ebpf/ringbuf" "github.com/cilium/ebpf/rlimit"
AI Agentの叛逆により、ホームディレクトリを破壊された人が話題となった。LLM無職を差し置いてLLMホームレスである。 ん？え？は？何してるの？ pic.twitter.com/QaDkToek4P— /mugisus/g (@mugisus) 2025年7月1日 かわいそうに。AIはこういうとき全く躊躇なく余計なことをする*1ので、自分も閉口することがある。明日は我が身ということで、叛逆に備える方法を探る必要がある。 ところで、環境の隔離というと最近はすぐコンテナが出てくるけれど、コンテナみたいな大仰なものを使わなくとも、実行するプロセスに強制的なアクセス制御をかけて特定のディレクトリにしか書き込めないようにするグッズがいろいろあって、例えばSELinuxやAppArmorといったソフトウェアを利用できる。これらは多くのディストリビューションにデフォルトで入っており、人知れずお前ら
はじめに 「RustでeBPFを操れるAyaを触ってみた」という記事で、Rust で eBPF のプログラムを書いて、Linux カーネルが提供する tracepoint にアタッチしてシステムコールの呼び出しをトレースするという話を書きましたが、引き続き、ユーザレベルのライブラリコールをトレースする話を書いてみたいと思います。 準備 今回の環境は以下の通りです。 Ubuntu 24.04.1 LTS (amd64) / Ubuntu 22.04.5 LTS (aarch64) Linux 6.12.7 (メインラインのソースを独自ビルド) / 6.8.0-50-generic rustc 1.85.0-nightly (dd84b7d5e 2024-12-27) cargo 1.85.0-nightly (c86f4b3a1 2024-12-24) Aya を使うためには以下の準備が必要
背景 Linux networkingには下記のような様々な構成要素があります。 ネットワークデバイス 経路テーブル フィルタ etc. これらを操作する必要がある場合、一般的には iproute2 などのコマンドラインツールから操作を行うことが多いかと思います。 しかしOpenStackやKubernetesなどの大規模なクラスタを管理する環境では、複数ホストにまたがってネットワークを動的にかつ一貫した方法で構成することが求められます。 こうしたニーズを実現するために、Linux networkingの構成要素を自作のプログラムから直接制御することが最も効率的な場合があります。 NetlinkというLinuxのサブシステムはLinuxカーネル内のネットワーク関連リソースを制御します。このNetlinkサブシステムを活用することでネットワーク管理を自動化することができます。 概要 Netl
ユニットテストにおける時間の問題についてのTipsです。 ユニットテストを行う際に手間のかかる作業として、テスト用環境の構築があります。 今はDockerがあるのでかなり手間が減りました。 ユニットテストは何度やっても同じテストができて、同じ結果になることが重要ですが、その際に問題となるのはシステム日時です。 「今日」とか「今月」などの日付・時刻によって返す結果が変わる処理があった場合にどうやって環境を設定しておけばよいか。 Docker Composeとlibfaketimeを使ってシステム日時を固定することができます。 以下、PythonのWebフレームワークであるDjangoをサンプルとして方法を紹介します。 他の言語、フレームワークでも基本は同じになります。 1. Dockerfileでlibfaketimeをインストール FROM python:3 ENV PYTHONUNBUF
はじめに Python3.9の新機能 (まとめ)という記事を書く中でpidfdというものを知りました。まだあまり良い解説記事がないのですが、最近の5.x系Linuxカーネルに新たに導入されたプロセスを識別するための仕掛けです。この機能がRust言語でCrate（ライブラリのようなもの）として実装されていたので試してみました。 pidfdとは これまでプロセスはPID(Process ID)によって指し示されていました。PIDはプロセスを一意に指し示すための識別子で、例えばシグナルなどを送ったりするのに使われます。 PIDは32bitの整数で、プロセスが生成される時にカーネルが割り振りますが、システム全体で共有しているので枯渇しちゃいます。32bitならそこそこあるように思いますが、実はPIDの最大値はもっと小さく設定されています。Linuxの場合は cat /proc/sys/kernel
RustでRISC-Vエミュレータを書いてNOMMU Linuxをブラウザで動かした #2023-05-23 以前からRISC-Vエミュレータを書いてみようと思っていたのだが、書いては飽きてを繰り返して全然進められずにいた。そんな中、以下のRepositoryで、rv32ima,Zifencei,Zicsr、あとはCLINTを実装すればLinuxが動くと知り、飽きずに進められそうな気がしてきたので今度こそ、と実装してみることにした。 https://github.com/cnlohr/mini-rv32ima目次成果物 #Repositoryは以下。本記事では実装の概要の記載もあるが、簡略化していたり抜粋だったりするので適宜参照いただきたい。基本的にはcoreというcrateが実装の中枢となっている。appはcoreにcliの皮を被せただけだ。 また以下にPlaygroundも用意した。
ふつうのLinuxプログラミング Linuxの仕組みから学べるgccプログラミングの王道 作者: 青木峰郎出版社/メーカー: ソフトバンククリエイティブ発売日: 2005/07/27メディア: 単行本購入: 35人 クリック: 450回この商品を含むブログ (145件) を見る ふと軽い気持ちで手に取った入門本であるが、いやはや驚いた。 入門本のかくあるべき姿がここにあったのだから。 「ふつうの Linux プログラミング」の内容はタイトルが表している通り、ふつうの Linux プログラミング。 cat コマンドや head コマンドを C で実装しながらプロセスやファイルやパイプの仕組みを学んでいく、というある程度 C 言語を知っている人向けの入門本である。一見巷にありふれていそうなふつうの本であるが、本書はひときわ輝いている。プロセスやファイルやストリーム等々の概念の説明もわかりやすく
今年に入って Octopassというプロダクトを公開しました。それは、Linuxのユーザや権限をGithubのTeamと連携して運用を楽にするというツールでした。色んな方々のご協力により、多くのRetweetやはてぶいただいたことで、ある程度、Octopass を必要としそうな人の目に触れたのではないかと思っています。（Githubのスター数が少ないのは今後の課題）その中で「すごく便利」「ぜひ導入したい」というフィードバックは、継続して機能追加していくというモチベーションにつながっていて、非常にありがたいです。 さて、この Octopass は、Linuxユーザ名前解決をするためにの glibc の libnssモジュールをCで実装しています。cgoやその他の言語でShared Objectを吐き出しても良かったのですが、それだと技術的挑戦が足りないとして、触れてこなかったCに挑戦しました
概要 原著者の許可および指示により「非公式の翻訳として」翻訳・公開いたします。 英語記事: Spying on a Ruby process's memory allocations with eBPF - Julia Evans 原文公開日: 2018/01/31 著者: Julia Evans なお、eBPFはBPF（Berkeley Packet Filter）の拡張版（extended BPF）です。 参考: LinuxのBPF : (1) パケットフィルタ - 睡分不足 参考: LinuxのBPF : (3) eBPFの基礎 - 睡分不足 今回は、CPUプロファイラを使う代わりに、まったく新しいアイデアに基づいた実験を披露いたします。 私がその日の朝に思いついたのは、Rubyの任意のプロセスのPID（既に実行されているプロセスのPID）を取得してメモリアロケーションを追えるのでは
はじめに こんにちは、ジーニーR&D本部アド・プラットフォーム開発部の宮下です。 今日は弊社の開発業務で普段どんなことをしているのかな、 という業務の一旦を弊社プロダクトのGenieeDSPを例にとってご紹介したいと思います。 現象 GenieeDSPは、弊社のDSP広告配信システムでSSPから来るリクエストのうち、おおむね月間800億リクエストを処理して、広告を返しています。 ある日のこと、監視システムから、配信サーバーの一台で負荷が高まっていることを示すアラートが上がってきました。 ジーニーでは各サーバーの稼働状況をモニタリングするものとして、Grafanaというツールを使用しています。 この時の状況でいうと、 CPU使用率は30%程度 load averageはほぼ限界まで高まっている(全てのCPUが処理待ち）という症状でした。 現象はリクエストの多い時間帯で起きており、症状の起きた
netfilterは、LinuxカーネルのネットワークスタックのいろいろをフックしてあれこれするためのAPIです。身近なところだと、iptablesやnftablesの実装に利用されています。カーネル内のAPIなので敷居が高そうに思われるかもしれませんが、簡単なLoadable Kernel Module (LKM) を書くだけで利用でき、カーネルに直接変更を加える必要がないので、かなりお手軽です。それでいて、iptablesやnftablesでも利用されているだけあってできることの範囲は広く、パケットの監視やファイアウォールを始めとしてパケットを読み書きするような処理なら割と何でもできます。 この記事では、netfilterを使うカーネルモジュールの基本的な書き方を紹介します。なお、動作確認はKernel 3.14で行いました。カーネルのバージョンによってメンバや定数の名称が変化している
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 社内で Linux マシンのとあるドライバの挙動がおかしいということで「ライブ crash で見たいなぁ」って呟いたら、「クラッシュって何？壊すの？」という反応が出て自分としてはカルチャーショックを受けたので、メモリダンプ解析の話を書いてみようと思いました。 色々と検索してみたところ、kdumpでメモリダンプ (世の中的にはクラッシュダンプと言う方が多い？) を採取する設定・手順についてはたくさんあるんですが、実際にその解析をどうやるのかって記事はあんまりないなぁと。パッと見つかったレベルだとこんな感じ。英文記事も探せば出てくるの
最近プロダクション環境での諸々の調査に使いたいというモチベーションで BPF Performance Tools (Book) 読み進めつつ、提供されているbcc-toolsを試したりbpftraceでlibほげほげの関数パラメータを抜いたりしていた、のだがUSDTを使用したトレースはうまく動かせず悶々としていた。 正直USDTはパッケージ入れておけばいきなりproductionでさくっと使える、という感じでもなく当初の目的からはやや外れているのだが、機構があるのに動かせないというのはなんとももどかしいので、諸々試行錯誤してとりあえず動いた、というころまでの記録を残しておく。対象はphpで。 なぜphpなのかというと、プライベート的にもお仕事的にも馴染みがありワンチャン使える可能性もあるのでは・・という期待と、ツールを試す過程で標準パッケージのphpで $ tplist-bpfcc -l
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
