忍者ブログ

素人翻訳

適当に翻訳する。

Windows Vistaの「マイコンピュータ」にSSDが表示されない

 linux機で外付け SSD を FAT32(LBA)形式に初期化し、ファイルをいくつか書き込んだ。それを Windows Vista で見ようとしたところ、Vistaでは SSD の内容が全く表示されなかった。Windows Vista に SSD を接続した時、デバイスドライバが正常にインストールされましたと報告されるが、「マイコンピュータ」には SSD が表示されない。linux では読み書きできるのに。

 この現象は、ファイルシステム構築(mkdosfs)のやり方が拙かった所為かもしれない。

 fdisk でパーティションを作ったあと、「/dev/sdb」にファイルシステムを作ってしまった。

[user15@localhost ~]$ sudo fdisk /dev/sdb
[user15@localhost ~]$ sudo fdisk -l
...
...
Disk /dev/sdb: 500.1 GB, 500107862016 bytes
ヘッド 81, セクタ 63, シリンダ 191411, 合計 976773168 セクタ
Units = セクタ数 of 1 * 512 = 512 バイト
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスク識別子: 0x1fd01bb0

デバイス ブート 始点 終点 ブロック Id システム
/dev/sdb1 2048 976773167 488385560 c W95 FAT32 (LBA)
[user15@localhost ~]$ sudo mkdosfs -F 32 /dev/sdb
mkdosfs 3.0.11 (24 Dec 2010)
mkdosfs: Device partition expected, not making filesystem on entire device '/dev/sdb' (use -I to override)
[user15@localhost ~]$ sudo mkdosfs -F 32 -I /dev/sdb

 こうして出来たファイルシステムは、linuxでは読み書き可能だが、Windows Vista には認識されない。

 一度全部消して、「/dev/sdb1」にファイルシステムを作って解決。

[user15@localhost ~]$ sudo fdisk /dev/sdb
[user15@localhost ~]$ sudo fdisk -l
...
...
Disk /dev/sdb: 500.1 GB, 500107862016 bytes
ヘッド 81, セクタ 63, シリンダ 191411, 合計 976773168 セクタ
Units = セクタ数 of 1 * 512 = 512 バイト
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスク識別子: 0x1fd01bb0

デバイス ブート 始点 終点 ブロック Id システム
/dev/sdb1 2048 976773167 488385560 c W95 FAT32 (LBA)
[user15@localhost ~]$ sudo mkdosfs -F 32 /dev/sdb1

 これで Windows Vista の「マイコンピュータ」で表示されるようになった

PR

X11におけるGraphics Context

 X11 のグラフィクス・コンテクストは、
・X10 の反省から生まれた。
・描画関数が受け取る引数の中のあるものを纏めたもの。

=====

参考論文
「The X Window System Version 11」
James Gettys、Philip L. Karlton、Scott McGregor
CRL 90/08(6頁、26〜29頁、33〜36頁など)

=====

Graphics Context の狙い

 X11 から GC(Graphics Context)の利用が始まった。X10(X バージョン 10)では使われていなかった。X10 では、描画関数を呼び出す度に、必要な情報すべてを引数で渡していた。VAXstation 100 に倣った「state-free」な描画手続きである。このやり方のまま X10 にない描画機能を追加していくと、描画関数の引数が増えすぎる。Xクライアント・Xサーバ間の通信量や、関数インタフェイスの複雑化が問題。

 GC を用いた「state-based」な描画手続きだと、
(1)描画リクエストで使う資源の初期化(リソースIDの割当て等)の手間・通信量が減る。
(2)描画リクエストの引数の数が減ることによって、リクエストそのものが小さくなり、Xクライアント・Xサーバ間の通信量が減る。
(3)描画リクエストの関数定義は、引数の数が減ってスッキリする。

 XクライアントとXサーバとの接続を表す情報塊の中にウィンドウと描画文脈の情報を含めるかどうか、あるいは「ウィンドウ」を表す構造体の中にグラフィックス・コンテキストを含めるかどうか、検討された。こうしたやり方だと、GCを用いる現在のやり方よりも描画処理のオーバーヘッド(通信量)が一層減るものの、マルチ・スレッド環境への対応が大変で、「ウィンドウ」構造体が大きくなりすぎる。そこで、X11では描画リクエストの度に「ウィンドウ」と「グラフィクス・コンテクスト」を指定することになった。

GC の効果

 GC の採用によって、Xlib の描画手続きは一部の引数をプロトコル・リクエストから取得し、残りの引数を同リクエストで指定した GC から取得するようになった。毎度毎度同じ値が指定されるような引数は GC の一部として記録されるようになったので、描画リクエストのサイズが小さくなった。

 どの引数を GC に入れ、どの引数を入れないのか、決めるのが大変だった。頻繁に値の変更される引数を Graphics Context に入れてしまうと、GC の内容を変更するリクエストと実際の描画リクエストの二つを描画の度に送信しなければいけなくなる。最終的に現在の23個をGCに入れることにした。Xlib.h の構造体「XGCValues」の通り。フォントなども GC に含めることになった。頻繁にフォントを替える場合には、複数の GC を用意して、描画の度に指定する GC を替えるようにすれば、GCの内容を変更するリクエストを何度も送らなくて済むと考えられた。

 GC がなければ、

XFillRectangle(display, drawable, gc, x, y, width, height);

は次のようになっていた。

XFillRectangle(display, drawable, x, y, width, height, function, planemask, foreground, background, tile_or_stipple, ts_x_origin, ts_y_origin, clip_x_origin, clip_y_origin, clipmask);

問合せ不可

 X11プロトコルでは、アプリケーションはGC等の内容をサーバに問い合わせることができない。一度でもアプリケーションの手元にあった情報は、アプリケーションが自力で記憶しておくものと決めた。

 関数 XGetGCValues は、Xlib が記憶している GC のキャッシュを調べて、その値を返す。X サーバには問い合わせない。

カレンダー

06 2020/07 08
S M T W T F S
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

最新コメント

[04/05 NONAME]

ブログ内検索

広告

バーコード

広告