Linuxにおける論理アドレスと物理アドレス間の変換(virt_to_physとphys_to_virtとioremap)

物理メモリと仮想メモリのアドレス変換が出来なくて困っていた。

意外とちゃんと説明しているサイトは少ないようだ。

どのサイトもvirt_to_physとphys_to_virtを使えば良いということであったが…

virt_to_physとphys_to_vortを使うにはC言語の範疇には収まらないものをincludeしなければならない。具体的に言えばカーネルのヘッダーだ。

#include <asm/io.h>

こうして変換してみたものの、ペリフェラルにアクセスするとカーネルが落ちてしまった。

実はphys_to_virtは完璧な訳ではなく、io空間にアクセスするにはioremapを使わなければならないらしい。

ということでまとめてみると、

  • 論理アドレスから物理アドレス
    • virt_to_phys
  • 物理アドレスから論理アドレス
    • 元々virt_to_physで変換したアドレスやプログラム中で確保されている領域
      • phys_to_virt
    • ペリフェラル
      • ioremap

となります。

ハードウェア設計者のソフトウェアコーディング力維持

自分がハードウェアのことばかりを考えるようになってから久しいが、最近コーディング力の減少に悩まされている。
アルバイトを辞めてからだろうか。いや、あのバイトがコーディング力維持に役に立っていたとは思えない。
Atcoderの問題が全然解けなくて焦るばかりだ。
心が折れそうだ

プログラマーという職

プログラマーという職は100年後も残っているだろうか。

情報工学を扱っている人間としては残って欲しい気持ちが半分、残ってほしくない気持ちが半分だ。

なぜかって、当然プログラミングを機械が行う時代が来ると思っているからだ。

PEZYは本気でシンギュラリティを目指している。計算量的に十分なハードウェアが出来るのは時間とお金の問題だろう。(もしかしたら政治的な問題にも発展するかもしれないが)

そしてソフト的な面で言えば、Googleがやってくれると信じている。
googleがどの程度中を作れているかは分からないが、きっとやってくれるだろう。

僕はこの2社がコンビネーションすることでシンギュラリティに達成出来ると思っている。つまりプログラミングの行為そのものが人間が機械に頼むという行為に取って代わられる時代になると思っている。

一方で計算機科学自体が取って代わられることも機械学習の理論が廃れることも無いだろう。消されるかもしれないのは人間と機械の間のインターフェイスを埋めるというあまり本質的ではない部分だ。

基礎を大事にして勉強していきたいと今一度思う。

コンピュータアーキテクチャとセキュリティ

最近のCPUは早いんだからアーキ自体にもっとセキュリティの機能を付けようという発想のコンピュータアーキテクチャ開発の話を聞いた。(読んだ)

確かにそのとおりである。今のアーキテクチャは古い時代に設計されたものが主でセキュリティ関連の甘さを感じることは多い。

特にメモリのアクセス管理はアーキの部分に押し込めるべき部分だ。今まではMMUを使って特権モードとユーザーモードで区別してきたが、正直これだけだとゆるすぎるだろう。プロセス別に分けることを考える余裕はあると思う。

 

ただ、ここで書いたセキュリティをより強化すべきCPUは全てのCPUに当てはまるわけではない。当然組み込み(やHPC)は別に考えてしかるべきだろう。

アーキにおいて重要なのはバランスだ(うちの先生は「トーレドオフが重要」が口癖)