iijlab

iijlabセミナー: ドローン前提社会 〜デジタルテクノロジーが包含するモビリティの未来像〜

IMG_20190618_174619

交差点でNHK撃退シールをくばってたけど無視して会場へ。

IMG_20190618_174842IMG_20190618_174957

[2019-06-18 18:01]

なかなか話者が来なくて連絡もないようで関係者がやきもきしてたが、1分遅刻で話者到着。

[2019-06-18 18:02]

  • SFCでipv6書いてた。
  • 「ドローン前提社会」は自分がつくった言葉。
  • 昔のSFでは飽和した地上から空を一人乗りの乗り物で移動してる未来が描かれていた。
  • フクイチを無人ヘリで調査したりした。
  • (ここで毎回やっているというドローンでの記念撮影。機体はDJI)
  • ラジコンの延長というよりはインターネットの延長と考えている。
  • 今は無線で直接つないでいるけど5Gでつながるようになるはず。IoTとおなじ。
  • 地上とランデブーするはず
  • droneとは雄蜂のこと。雄蜂は仕事しないで巣にいるので転じてヒモ・役立たずの意味もある。
  • droneの語源はイギリスの queen bee という無人飛行機(1936)から。
  • ドローンは無人航空機: UAV 人をのせられない (一人乗りのドローンもあるけど..)
  • 回転翼 プロペラが多い方がリダンダンシー(墜落しにくい)
  • 固定翼のもある
  • ドローンが官邸に落ちる前はドローンは模型飛行機のあつかいだった。
  • 実はやっと法律がかわって飲酒運転が禁止になった。
  • フィクションだが: マイクロドローンに3gの爆弾をもって顔認識で頭をねらう。流れ弾がない。→ 兵器にAIをつかってはいけないという主張 (autonomousweapons.org)
  • ドローンはプロペラがついたスマホとみなせる(スマホとつかうセンサーなどの部品が似ている)。中国のドローンが強い理由。
  • ドローンが飛ぶ方法は3つしかない: 浮力・推力・揚力
  • ドローン:自律的に移動する(空中だけでなく地上も水中もあり)
  • 昔は制御がアナルグだったが今はデジタル。
  • PID制御とカルマンフィルターと重心のオートチューニング
  • 自立性がラジコンとのちがい (勝手にバランスをとってくれる)
  • mavlinkという簡単なプロトコルがつかわれている。
  • 実はつかっているチャンネルは1つではない。
    • テレメトリーは別チャンネル 900MHz
    • コントローラは 2.4GHz
    • 映像は は5.?Ghz
  • PWMでモーター回転数制御していたが今はベクトル制御でトルクが上がった。(ドローンが進歩した理由?)
  • ドローンは進むときに傾かないといけない。
    • レーシングドローンは80度くらいまでかたむく
  • ドローンの上で倒立振子も簡単にできる (ただし棒の先端にはトラッカーをつけてモーションキャプチャーしてる)
  • ドローンで釣(drone fishing): 陸から仕掛をドローンではこんでポイントに投下する。上からだと魚影がよく見える。
  • 中国: 高圧線にひっかかったゴミをドローンの火炎放射器でやきはらう。
  • 200kg持ち上げられるドローンでビルの窓掃除。ただし水は地上からホースで。消防にもつかえるかもしれない。
  • sharkspot: 画像認識で海のサメとイルカとクジラと人を認識して警告するとか
  • ドローンの可能性: 視点・ポジション・インターネット・群れ行動
  • mavlink dronecode じゃなくてmqttでもいいいのではないか。
  • レーシングドローンはラジコンとかわらない。arudino シングルスレッドで。あまり処理できない。px4。
  • 逆位相プロペラで音を消してスピーカをうかすアイデア。
  • VAIOがドローンをつくっている。設計はnileworks。
    • ドローンで農薬散布: 画像認識することで、植物に元気がないところだけ肥料をまいたり、カメムシがいるところだけ農薬をまいたりでいる。いまの農業は確率的でおおざっぱ。
  • ドローン宅配は空だけじゃなくて陸路・水路も活用されるのでは。自立が需要。屋根・ベランダに宅配ポストができるかも。
  • cargo drone
  • ルワンダは陸路が整備されてない。固定翼ドローン zipline で医薬品を運ぶ。固定翼の欠点は離着陸に場所が必要なことだが、離陸はカタパルト 着陸はコードにひっかけてとめる。 オペレーションは現地の人でもできるように部品交換が最小限になるように工夫。
  • ドローンでレンガを積んで塔をつくる。位置制御が正確にできるため。

[2019-06-18 19:02]

  • みそらかなたちゃん: ドローンのためにつくったキャラクター
  • Q: ドローンの衝突はどう解決する?
  • A: UTM(UAV Traffic Management):管制システムをつくっている。
    • 無人管制の考え方はまだマイナーで有人管制の考えが強い。
    • 位置情報とベクトル情報を共有する。
    • open drone IDで識別。
    • WiFiを想定しているが5Gにも対応しようとしている。
    • まだこれからという段階。
  • Q: ドローンの制限事項に何があるか?
  • A: 風は古くから問題で対策されてきている。モーターの制御技術で状況に応じてトルクのだしかたをかえられる。
    • 伝送距離の問題は衛星通信をつかったり
    • 衝突回避
    • 距離はレンジエクステンダー(発電機を積む)もある
  • Q: ドローンを飛ばすには何か資格が必要か?
  • A: 免許はない。ルールはある。民法的には土地の所有者がダメといったらダメ。ざっくり200g未満、田舎で見える範囲で日の出から日没までなら自由といった感じ。

[2019-06-18 19:13]

  • 水中ドローンの通信は有線。
  • 回転(yaw)はおたがいに逆回転しているローターの回転数を変えるとできる。このため原理的にゆっくりとしか回転できない。

帰りにまだNHK撃退シールをくばってたのでもらって帰ってきた。

IMG_20190618_215330

iijlabセミナー: 狭義のTeXと広義のTeX、それぞれの進化

IMG_20190521_174225

午前中は酷い雨だったけど夕方にはやんでくれた。

IMG_20190521_174613

[2019-05-21 18:01]

  • 日本人の知らないTeX/八登崇之 at TeXユーザの集い2010 を読む前提知識を提供するかんじで。
  • クヌースがつくったTeXはもうつかわれてない。つかってるのはクヌースだけ。
  • XeTeXはジーテックとよむ。
  • LaTeXはいじらない方針だったけどTeX Live 2015からは変えていく方針になった。
  • TeXのレイヤー: 文章を入力する人/文章を組版する人/仕組みを開発する人
  • webに対応させると HTML/CSS/JS
  • いきなりマクロ言語のところをいじるのは無謀
    • コアの部分をいじろうとしてハマるパターン
  • 図を書けるようにした: TikZ/PGF
  • LuaTeX: JSでDOMをいじるようなことがTeXでできる。
  • XeTeX(2004),LuaTeX(2007)でUnicodeに対応した。それまでは8bit化されてただけ。
  • pdfTeXにinputencパッケージでエンジンそのままでUTF-8(ただしグリフは255文字まで)対応してしまった。
  • TeXは \foo というコマンドだけでなく文字もコマンンドとしてあつかえる。
  • CJKパッケージもおなじ戦略だが文字が256文字におさまらないので256文字でサブフォントとして対応。
  • フォントはコマンドできりかえる。
  • tfm: 昔はフォントは印刷所にしかなかったり。フォントの概要だけを納めたファイル。
  • コミックだと漢字はゴシック、ひらがなは明朝だったり、フォントをくみあわせる需要がある。
  • DVIもフォントを仮想化する -> VF
  • NFSS: LaTeXにおける抽象化: encoding,family,series,shape,size
  • fontenc
  • フォントの設定だけで4つもファイルを用意する必要がある。
  • システムフォントをつかいたかった -> XeTeX
  • 日本語ならBXjsclsパッケージをつかうとすべてそろう。
  • pxchfonというパッケージをつかうとDVIをハックしてフォントがえらべるようになる。

[2019-05-21 19:08]

  • Q: uplatexじゃなくても日本語はつかえる?
  • A: luatexでも日本語処理のパッケージがあるので使える状態になっている。
  • Q: 若者育成は?
  • A: 若い人もいる。ptexを開発している日本人は25歳。

[2019-05-21 19:11]

_1240217x

IIJlabセミナー: 進化するロギング: デバッグのための古くて新しい技術

IMG_20190122_173812

ロギングはバグを特定するための古典的な手法である.ログとして記録してお
くイベントの品質が,そのままデバッグの効率に直結する.それにもかかわら
ず,従来のロギングでは開発者の経験と勘に基づいて
1) ログを出力するコード上の場所(where to log) と
2) 記録しておくべき情報 (what to log)
をアドホックに決定している.そのため,デバッグ時に必要十分な情報が得ら
れるとは限らず,デバッグを困難なものとする一因となっている.
本発表では,ログの品質を改善する「ロギングコード自動挿入」に関する最近
の研究成果を紹介する.ログの自動挿入はここ数年にわたって活発に研究され
ており,システムソフトウェア研究のトピックのひとつとなっている.既存研
究を概観したのち,発表者等が研究・開発を進めているロギング・ツールK9
について紹介する.K9 はマルチスレッド環境におけるエラー伝播を対象とし
ており,共有データを介したスレッド間でのエラー伝播の追跡を可能とする.
共有データを介したエラー伝播が発生すると,障害を起こしたスレッドのコン
トロールフローを遡っても,障害の原因となったバグにたどり着けるとは限ら
ない.K9 ではそのようなエラー伝播の追跡を支援する.実際に,K9 をLinux
カーネルに適用し,既知のカーネル・バグ 3 種の追跡が可能であることを確
認した.さらに,Linux のファイルシステム保守中に遭遇した未知の障害にも
適用し,バグの特定に有益であることを確認した.

IMG_20190122_174848IMG_20190122_175121

[2019-01-22 18:00]

  • 障害が発生したら(教科書的には): 再現→調査→対策
  • しかし:
    • そもそも再現がむつかしい。
    • 同じ実行環境が手にはいらない。
    • プライバシの観点からデータが手に入らない。
  • かわりのログを送ってもらいログを調査する。
  • しかし:
    • ログが膨大すぎて解析できない。
    • 肝心の手掛かりとなる情報がログにない。
  • 経験と勘に基づいたロギングが原因。
    • システムコールのエラー。
    • 例外的な処理。
    • 気分で入れてるだけ。
    • windows SOSP 2009
    • printf, log4j, syslog event tracing for windows (ETW)
  • 適切なログイングは難しい。
  • 専門用語:
    • logging too little: ログが少なすぎる
    • logging too much (redundant&trivial): 冗長だったり、あたりまえの内容だったり。オーバヘッド・ストレージ使用量が問題になる。
  • ロギングが研究テーマになったのは数年前から
    • 手動から自動へ
    • where to log?: どこに入れるか?
    • what to log?: どんな値を記録すればよいか?
    • what happend?: ログから障害発生の様子を自動抽出して障害の実行パスを類推する。
  • Errlog [Yuan+ OSDI'12]
    • どこでログを入れるか、入れわすれたところに自動でログを入れる。
    • 例外処理:
      • 実際にはログを取り忘れるケースが多い。250件の障害事例を調査。
    • error()を呼んでたらエラー処理というような判定をする。error()を呼ぶ条件式を集めて、ログを入れ忘れているところに追加する。プログラマは無能ではない前提。
  • SherLog [ASPLOS'10]
    • what happend? ログから実行パスを類推する。Sharはシャーロックホームズから。
  • LogEnhancer[ASPLOS'11]
    • 実行パスが類推できるように変数の値をロギングする。
  • K9ではLinuxをターゲットにした。
    • Linux as Infrastructure
    • Linuxは実用的・巨大・複雑なので、Linuxでつかえれば他のソフトでも使える。
  • 用語:
    • fault: =bug 誤りのこと バグがあっても踏まないと発症しない
    • error: バグをふんでおかしくなった状態
    • error propagation: おかしな状態は伝搬する
    • failure: 障害発生(クラッシュ・ハングアップ)
  • Palix:
    • Null: nullチェックもれ
    • Inull(Inconsistent null check): ポインタ参照(deref)したあとにnullチェック(意味がない)
    • Block: ブロックしてはいけないコンテキストでブロックする関数をよぶ
  • linuxにはだいたいいつでも700個くらいバグが残っている。
    • バグをつぶしても同じくらいバグが入ってくる。
    • 1行あたりのバグは減っている。
  • 簡単なバグだけではない
    • 関数にまたいだ問題
    • 割り込み(非同期)
  • Inter-thread error propagation
      • Btrfsでworker threadが例外時にdirtyフラグを落すのを忘れて
      • sync threadがBUG()を踏む
    • direct propagation: スレッド1が共有データを更新して、スレッド2が読む。
    • indirect propagation: スレッド1が共有データを更新して、スレッド2が読んで別の共有データを更新して、スレッド3が読む。
  • K9ではエラー伝搬を解析できるようにログを入れるが、linux規模のソフトでは正攻法は無理。
    • オーバヘッドを押える
    • 静的解析はしない
    • ポインタ解析はしない (やっても正確には分からないことが証明されている)
    • coding traditionを仮定して共有データをさがす。
      • 共有データはヒープに置かれる。
      • 共有データは構造体になっている。
        • そのなかのポインタ配列やリスト構造をみる。
        • リンクリストなどのデータ構造用のライブラリにも対応(対応しないとデータ構造を操作するだけの関数がログに出て呼び出し元が分からない)
    • indirect propagationはデータフローは追い掛けずに型レベルで推測する。
  • ファイルシステムにはバグが多いという論文がある and Btrfsは新しいファイルシステムなのでバグが多く残っているのでは? and 研究室の学生がBtrfsのメンテナ
  • Btrfsで未知のバグをK9で追い掛けた原因をつきとめられた (実証)
  • K9のオーバヘッドは、スループットで1.83%(平均)、CPU利用率で0.32%(平均)。
  • たまにスループットのオーバヘッドが少ないという論文があってもCPU使用率が高いケースがある。その場合はCPUに余裕がないとスループットが悪くなる。

[2019-01-22 19:16]

QA

  • Q: ログを入れたのはファイルシステムだけ?
  • A: yes。だがファイルシステムのコードから呼ばれている関数にもログが入っている。スケジューラとかメモリ管理とか。これら(sched,mem)にはバグが少ないという研究報告がある。クリティカルセクション内でログを吐かないようにすることで、よりオーバヘッドを減らせる余地がある。
  • Q: ロックには注目しないのか?
  • A: ロックの範囲を調べるのが簡単ではないのと、ロックが保護している変数を見つけるのも難しい。ロックもれがあった場合に困る。やってみたが良くなかった。
  • Q: K9の論文は公開されているか?
  • A: 投稿中。
  • Q: オープンソースにするのか? それとも企業に買収されるのを期待しているのか?
  • A: 日立との共同研究なので日立が買う可能性はあるが、オープンソースにする予定になっている。
  • Q: C以外の言語でもつかえるか?
  • A: LLVMの中間言語で解析しているので、言語に特化したものでなければいけるはず。

[2019-01-22 19:24]

IMG_20190122_194128

関連資料?

IIJLabセミナー: 不揮発性メモリ時代のネットワークスタックおよび ACM HotNets 2016 参加報告

image

[2016-12-26 17:59]

講師 本多倫夫氏 登場

[2016-12-26 18:03]P1120351x

PASTE: Network Stacks Must Integrate with NMVM Abstructions

  • NVMMs: non-volatile main memories
  • persistent
  • byte-addressable
  • low latency: 10s-1000s o ns (お値段による)
  • ファイル名が永続化するためのしくみ、とも考えられる。
  • direct mmap()-ed files
  • data structureが変ったらネットワークスタックはどう変るか?
  • case study: WAL(write ahead logging)
    • B-tree(メタデータ)のアップデートは時間がかかるので一旦logに書いてclientにackを返す。
    • データの流れ: client -> server: nic->dram->networkstack->(read)->app->(write/fsync,memcpy/msync)->storagestack->storage->..
    • 実験:
      • NVMe: 2000us。ネットワークはやれることはない。ストレージで律速。
      • NVMM: 42usくらいでおわる。ネットワークでやれることがある。
    • 実際には並列アクセスされるのでNVMMをつかっても(ネットワークだけストレージなしの時よりも)スループット/レイテンシは落ちる。
    • NVMMつかっても、まだまだ永続化するコストがある → メモリコピーによるキャッシュミス
      • rx_buf→app_bufのコピーはapp_bufが固定なので(キャッシュヒットして)コストは安い。
      • app_buf→log_file(NVMM)は毎回違う場所になるのでキャッシュミスしてコスト高い。
      • DDIOがあるのでNIC受信はLLC(last level cache)にいきなりヒットするのでキャッシュミスがすくない。
      • kernel内のmemcpyはユーザ空間のmemcpyに比べて最適化されてない?のでキャッシュミスが多くなる。
    • 受信バッファ(in kernel)をNVMMに置けば解決。/mnt/nvmm/pktbufs とか。ログは /mnt/nvmm/appmd (アプリメタデータ) に。
  • FAST Logging with PASTEP1120352x
    • NICがrecvした段階ではLLCに乗っているだけでflush(clflush)してはじめて永続化する。
    • clflushはキャッシュライン単位でフラッシュする。msyncはページ単位。
    • データはNVMMのポインタをコピーすることでmemcpy回避(コピーするのはメタデータだけにする)。
    • netmapを改造して実装。 pkg-gen -i eth1@/mnt/pmem/bufs -f rx
    • tcp/ipはstackmapをつかっている(先行研究)。
    • ざっくり thruput 10%up, latency 40%up した。
  • 関連研究:
    • NVMM関係ないネットワークスタック(高速ネットワーク)
    • NVMMつかったファイルシステム(高速ファイルシステム)
    • NVMMだけどRDMAつかってネットワークスタック関係ない(HPC系)
  • まとめ:
    • RDMAはどこでもつかえるわけじゃない!
    • 単体で改善するだけでは十分じゃない!

[2016-12-26 18:31]

  • Q: clflushをlazyにできるときもあるとおもうが
  • A: writeのlatencyが長いNVMM(3dxpointとか)もあるので、アプリがLLCをflushするかどうか決めるようにしている。トランザクションの永続化要求はアプリによってちがう。multi-coreのときにスケールしないかもしれないのはfuture work.
  • Q: いま売られているものと今後でてくるものはちがってくるとおもうが、どうなる?
  • A: いま売られているのはbattery-backupedで速いやつなので、3dxpointみたいな遅めのやつでは.. 研究者はfpgaでemulatorかdramで実験している。
  • Q: フラグメントしない?
  • A: ほんとうに保存(リングバッファから別の領域に?)しおわってはじめて回収できるようになる。netmapでdouble bufferingがあるので穴あきもんだいはok。

[2016-12-26 18:39]

Report on ACM HotNets 2016 P1120353x

  • 90人くらいなので学内ワークショップなフレンドリーな雰囲気。
  • frontier network: 辺境の地でのネットワーク
  • MPTCPでマルチホームのときに他のISPにトラフィックをおしつけたり
  • RDMAが流行り
  • datacenterでマルチリンクのときにトポロジをどうするとか
  • RDMAでpriority-basedだとデッドロックしちゃうのでどうしようとか

[2016-12-26 18:48]

  • Q: もりあがってた話題は?
  • A: 発表時間がかぎられているので、どの話題もそれほどもりあがらない。
  • Q: 気になったのは?
  • A: internet blockchain(BGP,DNSをやめようというやつ)がおもしろかった。
  • Q: MPTCP ホットポテト問題? (ホットポテトってこれか?)
  • A: ISP間の公平性の問題提起。appleがECNでREDやってるけどISPでもやるの?とか。

[2016-12-26 18:52]

  • Q: ネットワークスタックをどうかえたい? pullupじゃなくて、とか。
  • A: netmapはlinuxには絶対入らないし、freebsdにはNVMMがないし、アプリ専用のスタックをつくるのは懐疑的(カーネル内のプロトコルスタックは複雑なので触りたくない)。
    • FreeBSD: RAMとして見えるけどpageをどうみせるとかグルーの部分がぜんぜんない。そもそも人がいない...
  • Q: RDMAきらい?
  • A: LLCにRDMAする話はきかないし、あまり議論するつもりがない。(ちなみに会議にはHPC屋はいなかった)
  • Q: DDIOは3種類: 1:ringbufだけ、2:メタデータも、3:ペイロードも。
  • A: ペイロードありで実験している。

[2016-12-26 18:59]

飯田橋駅工事中で、西口に活気がない感じがした。

P1120355x

IIJlabセミナー: Linux Kernel Library: 再利用可能なモノリシックカーネル

image

  • 動機
    • ネットワークシミュレータの研究をしていて、シミュレーションと実機とで二重にコードを持ちたくなかった。
    • Linuxのネットワークコードは618KLoCもある。
    • だからといってシミュレーションするときにLinuxをVMで動かすと遅い。
    • 新しいソフトを使うときにVMで検証してる?
      • マイクロソフトでさえ頻繁に検証するわけではない実態。
    • (一般的にいって)性能と利便性のトレードオフがある。
    • 問題はindirectで解決できるという名言。
  • AnyKernel (NetBSDというOSのrump kernelみたいなもの)
    • clock,memory,scheduler,deviceIO(NIC,blockdev)だけがarchitecture dependで
    • その上にarch independentな層、さらにその上に(改造なしの)カーネルをもってくる。
    • カーネルの上にAPIを被せてアプリケーションはAPI経由でカーネルを利用する。
  • やりかた
    • Arch independentな層を入れたり
    • 抽象的なCPU archを導入したり
  • アプローチ
    • フルスクラッチ: mirage, includeos, seaster, mtcp
      • 性能的に有利
    • 移植: OSv, libuinet, sandstorm
      • 最新版への追従性に難
    • anykernel(移植ではなくそのままもってくる): NetBSD rump, UML, DrawBridge(マイクロソフト製,論文からするとおそらく)
      • カーネル資産をつかえる、最新版への追従性も良好
  • LKL: Linux Kernel Library
    • https://github.com/lkl/linux
    • カーネルのライブラリ化
    • 2007年にルーマニアでスタート(rumpと同時期)
    • IOはいまどきのvertio
    • win32,linux,freebsdなどの上で動作
  • DCE/LibOS
    • 2008年スタート
  • LKL vs LibOS
    • LKLはpthreadでIRQ,kthread,timerを実装
    • LibOSは高位APIをpthreadで実装
  • デバイスイタンフェース: TAP, DPDK, VDE
  • wrapperの規模は2400LoC、CPU非依存
  • ホストOSにはNT,POSIX,MacOS,Linuxがつかえる。
  • LKL APIの種類:
    • (1) LKL syscall: ふつうのsyscallに相当: lkl_sys_hogehoge()
    • (2) Hijack Lib: LD_PRELOADでsocket()をlkl_sys_socket()に曲げたり. linux以外ではsyscall emulatorが必要になる
    • (3) extended(alternative)libc: musl(マスル)。 libcを拡張してアプリに機能を提供。
  • アプリケーションの例
    • ns-3(ネットワークシミュレータ)
      • ns-3の中でLKLを読み込んでネットワークスタックを利用する。dlmopen
      • 実機とちがってタイミングが毎度同じなので再現率100% (仮想クロック使用時)
      • valgrindでデバッグできる。
    • 簡易カーネルバイパス
      • LD_PRELOAD=hogehoge-tcp.so firefox などとして、ホストカーネルとは異なるネットワークスタックをつかってみたり。
    • ext4読み書き
      • windows上でext4のディスクにアクセスする。
    • unikernel
      • 単一アプリにカーネルをリンクする、小さなゲストOS。rumpに似ている。
      • たとえばping6コマンドにLinuxを埋め込むなど。
      • たとえばarm-qemu上でゲストOSを起動しないでpingを実行するとか。(pingにOSがリンクされている)
      • 今日の発表もこれをつかっているらしい。
  • 性能について (UDP 1000B)
    • native kernelがRTT/thruputともにベスト
    • DPDKはRTTがとんでもなく遅い。thruputも低い。
    • netmapとtapはthruputが低い
  • Q:コストは?
  • A: 初期化はふつうのカーネルよりも速い。デバイスの応答を待つ必要がないのと、不要なデバイス初期化をなくせるのとで。メモリフットプリントはとても大きい。おそらく実装の問題。らくらくGB越え。qemuでメモリサイズをGBにしないと動かない。
  • Q: 改造量は?
  • A: IRQ,threadなどだけをposixで実装して、他の下廻りはカーネルのコードをそのままつかっている。
  • Q: 昔のSunのマシンがやっていたメモリリフレッシュとかはどうなるだろう?
  • A: たぶんそのまま動く???
  • Q: ns-3での再現性100%はほんとうか?
  • A: パケットのキャプチャと再生はできるという意味ではyes。実行時のトレースはとっていないので、スレッドのインターリーブによる部分は再現できないだろう。
  • Q: ext4の例はどのレイヤでやっている?
  • A: ディスクイメージをLKLが解釈している。VFSはつかっていない(ホストOSのVFSのことか?)。
  • Q: LKLのデバッグは?
  • A: gdbでカーネルデバッグできる。
  • archLinuxベースらしい。

image

記事検索
月別アーカイブ
アクセスカウンター

    タグ絞り込み検索
    ギャラリー
    • 今日の練習 2019-07-21
    • 今日の練習 2019-07-21
    • 今日の練習 2019-07-21
    • 今日の練習 2019-07-19
    • 今日の練習 2019-07-19
    • 今日の練習 2019-07-19
    Amazon
    楽天市場
    adby google
    LINE読者登録QRコード
    LINE読者登録QRコード
    • ライブドアブログ