2011-06-01 :-(
_ バジルの花が咲く
_ [NetBSD][samba]/usr/pkgsrc/net/samba35
- 公式のSamba 3.2.x HOWTOとリファレンスガイド - Chapter 2. 手軽な始め方: 短気な方への手引き
- How to set up a Samba Server - NetBSD Wiki
そのまま
インストール
% cd /usr/pkgsrc/net/samba35 % sudo make install clean clean-depends
コピー
% sudo cp /usr/pkg/share/examples/rc.d/smbd /etc/rc.d % sudo cp /usr/pkg/share/examples/rc.d/nmbd /etc/rc.d % sudo cp /usr/pkg/share/examples/rc.d/winbindd /etc/rc.d/ % sudo cp /usr/pkg/share/examples/rc.d/samba /etc/rc.d
/etc/inetd.conf に書いて再起動するか、または
netbios-ssn stream tcp nowait root /usr/pkg/sbin/smbd netbios-ns dgram udp wait root /usr/pkg/sbin/nmbd
% /etc/rc.d/inetd restart
/etc/rc.conf に書く
smbd=yes nmbd=yes winbindd=yes samba=yes
/usr/pkg/etc/samba/smb.conf に書く
% testparm
:
[global]
dos charset = CP932
display charset = UTF-8
server string = Samba %v (%h)
hosts allow = 192.168.0., 127.
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
ユーザー追加
% sudo pdbedit -a rin
開始
% sudo /etc/rc.d/samba start
こんな
% smbclient -L localhost -U%
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.5.8]
Sharename Type Comment
--------- ---- -------
IPC$ IPC IPC Service (Samba 3.5.8 (yukina))
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.5.8]
Server Comment
--------- -------
Workgroup Master
--------- -------
2011-06-02 :-(
_ [gcc]gcc リハビリ
% gcc -I./lib -L./lib -lmisc 01/dirent.c /var/tmp//cc6tQdDd.o: In function `main': dirent.c:(.text+0x25): undefined reference to `err_quit' dirent.c:(.text+0x61): undefined reference to `err_sys'
ほむ?
% nm lib/libmisc.a
error.o:
U __errno
U __sF
U abort
00000000 t err_doit
00000132 T err_dump
000000d9 T err_msg
000000b6 T err_quit
00000117 T err_ret
000000f4 T err_sys
U exit
U fflush
U fputs
00000000 B pname
U sprintf
U strerror
U vsprintf
errorlog.o:
U __errno
U __sF
U debug
U exit
U fflush
U fputs
00000000 t log_doit
000000ff T log_msg
00000172 T log_open
000000d4 T log_quit
0000014e T log_ret
00000123 T log_sys
U openlog
U sprintf
U strerror
U syslog
U vsprintf
えー
なんでだろー
なんでだろー
% gcc 01/dirent.c -I./lib -L./lib -lmisc
あー
これはひどい
2011-06-05 :-)
_ 午後
1300 ケーキ
1400 C リハビリ
1500 RR7 TIME DOMAIN さん部屋に入ったらベースクルーザーの空気だった。skype に呼ばれたので駄弁りながらレースなど。今日の至言「エアニトロ」( by Papo )
_ おっさんが集うチャット
EEEEEEEEE「リッジって皆いまだにやってるんだよなあ。もう最初にやってたひとたちなんて居ないよね」
AAAAAAA「私は一時期やめて、また始めました」
XXXX「PS3 の他のゲームもやるんだけど、結局(リッジに)帰ってきちゃうんだよね」
2011-06-06 :-(
_ ミュージックダイアリー
サインインしようとしてみた。
Notice (8): Undefined index: oauth_token [APP/vendors/twitteroauth.php, line 118] Notice (8): Undefined index: oauth_token_secret [APP/vendors/twitteroauth.php, line 118] Notice (8): Undefined index: screen_name [APP/controllers/users_controller.php, line 30] Notice (8): Undefined index: screen_name [APP/controllers/users_controller.php, line 33] Notice (8): Undefined index: oauth_token [APP/controllers/users_controller.php, line 34] Notice (8): Undefined index: oauth_token_secret [APP/controllers/users_controller.php, line 35] Notice (8): Undefined index: screen_name [APP/controllers/users_controller.php, line 37] Warning (2): file_get_contents(http://api.twitter.com/1/users/show/.json) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found [APP/controllers/users_controller.php, line 38] Notice (8): Undefined index: screen_name [APP/controllers/users_controller.php, line 45] Notice (8): Undefined index: screen_name [APP/controllers/users_controller.php, line 51] Warning (512): SQL Error: 1048: Column 'screen_name' cannot be null [CORE/cake/libs/model/datasources/dbo_source.php, line 684] Query: INSERT INTO `users` (`screen_name`) VALUES (NULL) Notice (8): Undefined index: user_id [APP/controllers/users_controller.php, line 52] Warning (512): SQL Error: 1048: Column 'user_id' cannot be null [CORE/cake/libs/model/datasources/dbo_source.php, line 684] Query: INSERT INTO `users` (`user_id`) VALUES (NULL) Warning (512): SQL Error: 1048: Column 'profile_image_url' cannot be null [CORE/cake/libs/model/datasources/dbo_source.php, line 684] Query: INSERT INTO `users` (`profile_image_url`) VALUES (NULL) Warning (512): SQL Error: 1048: Column 'name' cannot be null [CORE/cake/libs/model/datasources/dbo_source.php, line 684] Query: INSERT INTO `users` (`name`) VALUES (NULL) Notice (8): Undefined index: screen_name [APP/controllers/users_controller.php, line 63] Warning (2): file_get_contents(http://twitter.com/friends/ids.json?screen_name=) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 400 Bad Request [APP/controllers/users_controller.php, line 64] Notice (8): Undefined index: oauth_token [APP/controllers/users_controller.php, line 78] Notice (8): Undefined index: oauth_token_secret [APP/controllers/users_controller.php, line 79] Warning (2): Cannot modify header information - headers already sent by (output started at /home/kamihiiii/music-diary.com/cake/cake/libs/debugger.php:673) [APP/controllers/users_controller.php, line 98] Notice (8): Undefined variable: join_id [APP/controllers/users_controller.php, line 102] Warning (2): Cannot modify header information - headers already sent by (output started at /home/kamihiiii/music-diary.com/cake/cake/libs/debugger.php:673) [CORE/cake/libs/controller/controller.php, line 746]
何度か試したらサインインできた。
ふむ
そういえば Last.fm にもブログがあったな miwarin ブログ - Last.fm
2011-06-09 :-(
_ 午後
1300 行列計算
_ [NetBSD][IPv6]hubertf's NetBSD blog - NetBSD and the World IPv6 Day
June 8th 2001 was announced as World IPv6 Day, where some major websites would increase adoption of the "new" internet protocol by actually using it.
2001 年 6 月 8 日 { 2011 年だよね?? } World IPv6 Day が告知された。いくつかの有名なウェブサイトは 新しい インターネットプロトコルを実際に使用することにより少しずつ採用している。
Interested NetBSD users have a variety of options to get NetBSD to talk IPv6, and Eric Haszlakiewicz has posted about his experience: ``If anyone else has been putting off setting this up because it seemed like it would be hard to do, I urge you to give it a shot.''
面白いNetBSD ユーザーは 様々なオプション により NetBSD で IPv6 をしゃべらせることが出来る。Eric Haszlakiewicz は 彼の経験について投稿した。「他にこれを設定するひとが居ないと、それをやるにはしんどいので、みんなもやろうよ」
To test ones IPv6 connectivity, there are several websites available.
2011-06-10 :-(
_ 夜
1800 仕事場歓迎会
_ [川上とも子][訃報] 川上とも子
ご冥福をお祈りします。
手元の日記を読み返したら懐かしいものを発見した。
2000/05/04 デジキャラフェスティバル
デジキャラフェスティバルに参加するために、朝っぱらから東京ビッグサイトに行ってきた。物版が主みたいなのだが、拙者は興味無い。
川上とも子のサイン＆握手会に参加(爆)、「ラブひなステージ」にて、堀江由衣さんを見た。会場は野郎ばかりなので、むさい。
(爆) とか懐かしい
あとこれくらい→ Kanon アニメ化記念イベント試写会＠池袋 東京豊島公会堂[ 20020113#p04 ]
_ ガッツキ
さらに懐かしいものをハッケソ
30 名前：声の出演：名無しさん ：02/01/10 05:43
中村
ayahtt
ゆーいち
あいつにホの字
m_nakamura
えふけん
伊川
つねみつ
おおぐち
えふ
錦
西川
ぱーそ
エト
河崎洋之
あまの
'MAGE
島野
みわ ←←←←←
山田
しのくん
ごん太
山田真弘
あに
たんに ML で発言してただけなんだけどここに名前が出てる
2011-06-11 :-)
_ 午前
1130 起床
_ ゴーヤの成長記録を晒すのが流行っているようなので便乗する
たださんとか 「緑のカーテン」を作るぞ(2) - 発芽した - ただのにっき(2011-06-04)
数ヶ月前に種を植えて、いくつか発芽したので鉢を分けるなどしてある。
たぶん種を植えたのは 4月9日のこれだと思うんだが( 中央の何も植えてないように見える鉢 )、ここで植えたゴーヤはたしか芽が出なくて、そのあと 5 月あたりにもう一度種を植えて、それがいま芽が出てゴーヤなんだが、このゴーヤはいつ植えたか正確なところは覚えてない。
_ [リッジレーサー7]リッジレーサー7 death@R研 4000 勝 && SYOURYU さん 4000 勝阻止レース
R研 のひと death さんの本アカ阻止レースの準備が整ったということで参加してみた。私がリッジ7 をプレイし始めたころにはすでに death さんは隠居状態だったので今日が初めての death レース。
阻止レースはカテゴリ 4 限定 && 逆走禁止。そんな条件で death さんと SYOURYU さんの同時阻止なんだが、無理ゲーすぎる。death さんブランクなんてウソじゃないのというくらいにあの速さおかしい。意味が分からないよ。1 時間くらいで 4000 勝達成。
その後はカテゴリランダムでテキトーに走るなど。death さんマジで速すぎだろ
- 走行距離 97656 km
- RSGP 進行度 100.0 %
- 名声 26513 FP
- オンラインバトル勝利数 1211/4383
2011-06-13 :-(
_ [PyGTK][Python][cygwin][Windows]Windows で PyGTK
卜部さんが「GTK プログラミング？ それ Python で出来るよ」と言っていたので ( 卜部昌平のあまりreblogしないtumblr - Pythonでおk ─ 書評: C言語によるスーパーLinuxプログラミング ) インストールしてみた。
上記サイトでは Python Windows 用バイナリと PyGTK Windows 用バイナリを使っているんだが、手元にはすでに cygwin の Python 環境があるしググったら pygtk 入れれば出来るよとのこと( ref. Mercurial/CygwinでTortoiseHgを使う方法 - TOBY SOFT wiki ) なので、あえて cygwin で行く。
cygwin の setup.exe を実行する
以下のパッケージをインストールする。PyGTK が X を必要とするので X も入れておく( ref. Setting Up Cygwin/X - Installing Cygwin/X )
python-gobject2.0 (2.20.0-2) Python GLib/GObject/GIO bindings (runtime) Required by: python-gtk2.0, python-gobject2.0-devel python-gobject2.0-devel (2.20.0-2) Python GLib/GObject/GIO bindings (development) Required by: python-gtk2.0-devel font-adobe-dpi75 (1.0.1-1) X.Org Adobe 75dpi fonts Required by: xterm font-alias (1.0.2-1) X.Org font aliases Required by: xterm font-misc-misc (1.1.0-1) X.Org miscellaneous fonts Required by: xterm, font-alias luit (1.0.5-1) X.Org Unicode Terminal Locale utility Required by: xterm xmodmap (1.0.4-1) X.Org keyboard modifier map and keymap table utility Required by: xinit xrdb (1.0.6-1) X.Org X server resource database utility Required by: xinit xterm (261-1) X11 terminal emulator Required by: X-start-menu-icons, xinit
% startxwin
これで X が起動する( X は client へ server が接続しにいくんだっけ )
起動したウィンドウの中の端末上で Python プログラムを実行する( cygwin のシェルから実行するわけじゃないようだ。ここんとこよく分かってない )。Python プログラムはこちらから貰った PyGTK入門 その1 ウインドウを表示する
2011-06-14 :-(
2011-06-15 :-(
2011-06-17 :-(
_ 夜
1800 突発鶏の会
_ ,
椿姫[ 20051209#p13 ]は文学になっちゃってるのであれば {キャバ嬢,娼婦,飲み屋の店員} に惚れてしまうのはなんら可笑しいことではない
_ [NetBSD][マルチブート][翻訳]making netbsd multiboot-compatible - o'reilly media NetBSD のマルチブート環境を作る
by julio m. merino vidal
03/01/2007
the i386 architecture is full of cruft required to maintain compatibility with old machines that go back as far as the 8086 series. technically speaking, these features aren't necessary anymore because any recent computer based on this architecture uses a full 32-bit operating system that could work perfectly fine without the legacy code. unfortunately, the compatibility hacks remain in place and hurt the development of new software.
i386 アーキテクチャは、8086 シリーズに遡るまでの古いマシンを維持するために cruft required している。技術的な話題としては、このアーキテクチャを基にした最近のあらゆるコンピュータは完全な 32 ビットオペレーティングシステムがレガシーコードが無くても完璧に動作するので、これらの機能はもはや必要とされていない。残念ながらここ( i386 アーキテクチャ )ではこの互換性ハックは生き残り、新しいソフトウェアの開発を悩ませる。
one of the details that has not changed for years is the i386 boot process. it was designed back in the days when computers had only floppy disk drives and machines had limited firmware. since then, the procedure has not suffered any change and it makes some tasks very complex; one of these is the configuration of multiple operating systems (oses) on a single machine.
ここ数年変化がないことのうち 1 つは、i368 ブートプロセスだ。これはコンピュータがフロッピーディスクドライブしか持っておらず、マシンが限られたファームウェアを使っていたころに設計されたものだ。その後、この手続きは苦労して変更されることなく、いくつかの処理はかなり複雑になった。そのうち 1 つは、1 台のマシンに複数のオペレーティングシステムを設定することだ。
the new firmware for intel-based machines, the extensible firmware interface (efi), resolves this issue by providing a more versatile boot process. other architectures have already provided improved firmware with nicer boot mechanisms, including, for example, the ability to load and execute an elf image straight from the machine initialization code. such is the case with openfirmware as shipped in powerpc macintoshes.
インテルベースのマシンの新しいファームウェア the extensible firmware interface (efi) は、多様なブートプロセスによってこの課題を解決した。他のアーキテクチャは、改善されたよりよいブート機構を持ったファームウェアが提供されている。たとえば、ロードする能力があったり、マシンの初期化コードから直接 elf イメージを実行できたりする。powerpc マッキントッシュの openfirmware のようなものだ。
even though alternative firmware implementations exist, the i386 architecture as we known it today will still be with us for a long time. therefore, it would be nice to resolve some of its limitations through software. this is what the multiboot specification attempts to do in the boot area: provide the ability to boot any operating system from a single boot loader, hence simulating an improved firmware.
他のファームウェアでは既に実装されているのに、i386 アーキテクチャでは今日に至るまでいまだに見たことがない。しかし、ソフトウェアの制限を通り抜けるようにした良い解決策がいくつかある。ブート領域でマルチブートするのである。これは、改良ファームウェアでシミュレーションすることにより、単独のブートローダーからあらゆるオペレーティングシステムをブートできるようになる。
i recently modified the netbsd's kernel to become multiboot-compliant. there are many code references in the text, but the main idea behind the essay is to introduce multiboot and show you that a real-world operating system can easily be converted to support this specification. please note that all code references point to the netbsd-4 stable branch to ensure that the code remains consistent with the explanations given here.
NetBSD のカーネルをマルチブートできるようにしてみた。大量のコードリファレンスがこのテキストに存在する。しかし主なアイデアはマルチブートを紹介する文章( 後述 )にあり、実際のオペレーティングシステムを簡単にマルチブート対応に変換することができるようになる。なお、全てのコードリファレンスは netbsd-4 stable ブランチを指しており、ここで説明したことがコードとして首尾一貫して残ることを保証する。
the i386 boot process (i386 ブートプロセス)
the traditional i386 architecture uses a very simple firmware known as the basic input/output system, or bios. the bios is in charge of initializing the hardware after powering up the machine and provides a low-level interface to access it from boot loaders and oses. unfortunately, it has inherited a lot of deficiencies from the past: these services are available from real mode only and they do not provide high-level abstractions for the underlying hardware.
伝統的な i386 アーキテクチャは、the basic input/output system または BIOS と呼ばれるじつに簡単なファームウェアを利用している。BIOS は、マシンの電源を入れたあとにハードウェアを初期化し、ブートローダーや OS がアクセスするための低レベルインターフェースを提供する。やっかいなことに、以下に示すような多くことを継承している。これらのサービスはリアルモードのみで有効であり、ハードウェアを高レベルに抽象化してはいない。
to put things in perspective, the bios is unable to access any on-disk filesystem (not even fat) and therefore cannot directly load any executable such as the os kernel. instead, all the bios does is load the first sector of the selected boot disk into a specific memory location (07c0h:0000h) and transfer the execution control to it. to make things worse, each os kernel has traditionally provided its own boot code tailored to its needs. for example, the old ms-dos os loaded from a fat disk and executed in real mode; on the other hand, newer systems can boot from a large variety of filesystems (fat, ntfs, ext2, and more) and need to run in protected mode from the very beginning because their kernels are too big to fit into the first megabyte of memory (all the memory addressable from real mode).
ここでの見方として、BIOS はディスク上のあらゆるファイルシステムにアクセスできないし( FAT は言うまでもない )、OS カーネルのようにあらゆる実行可能なものは直接接ロードすることができない。その代わり、全ての BIOS は、選択したブートディスクの最初のセクターをメモリ番地 07C0h:0000h にロードし、実行制御 { ってなに }をそこへ転送する。それが失敗した場合、各 OS カーネルは伝統的に自分自身のブートコードを必要なように仕立て上げることを提供する。例えば、古い MS-DOS OS は FAT ディスクかららロードされ、リアルモードで実行される。他に、より新しいシステムでは、様々な大きいファイルシステム( FAT, NTFS, EXT2 など )からブートする。それらのカーネルはメモリの最初のメガバイト( 全てのメモリアドレスはリアルモードに基づく )に格納するにはとても大きいので、しょっぱなからプロテクトモードで動作する必要があるだ。
the fact that each os needs its own boot loader causes a lot of problems when setting up several different systems on a single machine and poses a lot of questions that the user will most likely be unable to answer. what do you install in the mbr? where do you put each boot loader? why do you need to configure each of them independently? why do you need more than one?
OS 自身のブートローダーを使うと 1 つのマシン上でいくつかの異なるシステムを設定するときにたくさんの問題を引き起こすことになり、たくさんの問い合せが出るのだが、ユーザーはたいてい答えられない。MBR は何をインストールしてますか？ ブートローダーはどこに設置していますか？ それらを独立して設定する必要があるのは何故ですか？ 1 つ以上必要なのは何故ですか？
it could be very convenient if there was a generic interface that decoupled the load and bootstrapping of an os kernel from its boot loader. this way, an os developer could focus exclusively on the task at hand and forget about writing a boot loader. similarly, boot loader developers could join forces to write a more complete utility or, alternatively, write their own with minimal code, while being able to boot any os that supported such interfaces (ideally all oses). the good thing is that the grub developers already had this idea in the past and developed such an interface: multiboot.
もしブートローダーによる OS カーネルのブートストラップとロードとを分離する共通インターフェースあるならば、これはとても簡単に出来る。この方法ならば、OS 開発者は手持ちの作業のみに集中できるし、ブートローダーを意識せずに済む。同様に、ブートローダー開発者はもっと完全なユーティリティを書くことに注力するか、インターフェースに対応したあらゆる OS ( 理想的には全ての OS ) がブートできるようになるまでの間はそれら自身の最小限のコードとともに書いたりできる。良いものとして、GRUB 開発者たちは後述するアイデアを既に使っており、マルチブートのインターフェースとして開発されている。
the multiboot specification ( マルチブート詳細 )
the multiboot specification (ms) defines a protocol between boot loaders and os kernels that allows any multiboot-compliant boot loader to load and execute any multiboot-compliant os kernel. this permits the end user to install a single boot loader in his machine and use it to boot any system directly, without having to chain-load different boot utilities.
the multiboot specification (MS) は ブートローダーと OS カーネルとのプロトコルを定義している。これにより、あらゆるマルチブート対応のブートローダーでロードし、あらゆるマルチブート対応の OS カーネルを実行することを許す。この権限は、異なるブートユーティリティを連鎖することなく、エンドユーザーが自分のマシンにブートローダー単体をインストールし、あらゆるシステムをじかにブートできるようにする。
in order to accomplish this abstraction, the ms defines two items:
これを果たすため、MS は 2 つの項目を定義している:
- the multiboot header (mh) (マルチブートヘッダー (HM))
this is a 4-byte aligned data structure located within the first 8 kb of the os kernel image. it provides a magic number used to identify the file as being multiboot-compliant, a set of flags indicating specific kernel needs, and additional fields describing the structure of the binary. the latter are only used if the kernel is in the a.out format (with some exceptions); using elf makes things much simpler and also more versatile.
これは、OS カーネルイメージの最初の 8 KB に 4 バイトアライメントのデータ構造体を配置する。これは、マルチブート対応するためのファイルを見つけるマジックナンバーを提供する。
- the multiboot information structure (mis) (マルチブート情報構造体 (MIS))
this is a data structure constructed by the boot loader and passed to the os kernel as part of the boot process. it includes information such as which disk is the boot disk, a memory map, the kernel parameters, where additional kernel modules are in memory (if loaded at boot time), etc.
これはブートローダーによって生成される構造体で、OS カーネルのブートプロセスの部分として通過する。これには、どれがブートディスクなのか、メモリーマップ、カーネルパラメーター、追加カーネルモジュールのメモリ内での場所( ブート時にロードするならば )等の情報を含む。
there is some interaction between the two structures in the sense that the mh may request the boot loader to set some fields in the mis for a successful boot. if the boot loader cannot fulfill the kernel's needs, the load will fail gracefully.
ブート成功時にブートローダーが MIS 内のいくつかのフィールドを設定するように MH が 要求する、というように、2 つの構造体の間には多少の作用がある。もしブートローダーがカーネルの要求を満たせないならば、ロードは綺麗に失敗するだろう。
if you're making good use of these two structures, it's trivial to write a simple binary file that acts as an os kernel - that is, a binary that is able to run standalone on the machine without any other os. see the boot.s, kernel.c, and related files that form the example kernel distributed alongside grub in the docs directory.
もしあなたがこれら 2 つの構造体を良く使えるならば、それは、OS カーネルのような単純なバイナリファイル( それはマシン上で何の OS も無しに独立して走ることが出来るバイナリだ )を書くことは取るに足らないだ。boot.s, kernel.c や、たとえば docs ディレクトリ内の GRUB と一緒に配布されたカーネルなど、関連するファイルを読むとよい。
it is also interesting to note that a multiboot-compliant boot loader will enter protected mode and set up a preliminary gdt for a flat memory model, so the kernel needn't do this by itself. of course, the kernel will have to reload the gdt with values of its own later in the initialization process, but the one set up by the boot loader is enough to get started. in some sense, it's possible to write the os kernel as if the real mode did not exist at all, as happens on other (saner) platforms.
マルチブート対応のブートローダーがプロテクトモードに入り、フラットメモリモデルのための予備 GDT を設定することについて記すことはとても興味深いことだ。だからカーネルは、カーネル自身がおこなう必要がない。もちろん、カーネルは、初期化後にカーネル自身の値と一緒に GDT をリロードできなくてはならないだろう。しかしブートローダーによるセットアップについては、すでに始めることができる。ある意味、それは、まるでリアルモードが全てに存在しないような OS カーネルを書くことを可能にすることであり、他の( たしかな )プラットフォームが発生するようなものだ。
----------------------------------------------------------------------------------------------
_ [NetBSD][マルチブート][翻訳]making netbsd multiboot-compatible - o'reilly media NetBSD のマルチブート環境を作る(2)
the netbsd/i386 boot process (NetBSD/i386 のブートプロセス )
netbsd/i386 uses a two-stage boot loader. the first stage gets installed into a known physical location-typically, the first sector of the hard disk or partition in which the system is installed and spans over some other reserved free space in the filesystem. this little program, which is generally limited in size, has the required knowledge to read the second stage boot loader and transfer the execution control to it; this one installs into the root filesystem as /boot, so its physical location may vary across reboots: there is nothing in the filesystem that binds a file to specific disk blocks.
[[NetBSD/i386|http://www.netbsd.org/ports/i386/] は 2 ステージブートローダーを使っている。第 1 ステージは既知のインストール済みの物理配置を取得する。システム内のハードディスクかパーティションの最初のセクターはインストール済みであり、ファイルシステム内のいくつかの他の予約済み自由領域にわたっている。この小さいプログラムは、一般的にはサイズ制限されたものである。このプログラムは、第 2 ステージブートローダーを読み込み、それへ実行制御を転送するために必要な情報を持っている。これは root ファイルシステムの /boot へインストールする。そしてそれは、物理配置が再起動をまたいで変更されるだろう。ファイルシステムにディスクブロックの詳細に結び付けられたファイルは無いのである。
once the second stage boot loader receives control, it enters the flat protected mode (no paging, segments spanning the whole memory space), loads the kernel from disk, and runs it; it also accepts user input to choose which kernel to boot and which options to pass to it, if any. this loader also passes boot-time information to the kernel by means of the bootinfo framework. simply put, this is a table that contains information, all gathered by the boot loader, about the machine and execution environment, including:
第 2 ステージブートローダーが制御を受け取ったとき、フラットプロテクトモードに入っている( ページングは無く、セグメントはメモリ領域全体をまたいでいる )。ディスクからカーネルをロードし、走らせる。ブートさせるカーネルや、通過するためのオプション( あれば )を選択するためのユーザー入力も受け付ける。このローダーは、bootinfo フレームワークによるカーネルへのブート時の情報も通過させる。簡単に言うと、これは、以下に示すマシンや実行環境についてのブートローダーからの全ての情報を収集したものからなるテーブルである。
- amount of available memory
- the boot device
- the kernel's filename
- where the console is attached (e.g., serial line, local video card)
- 有効メモリの統計
- ブートデバイス
- カーネルのファイル名
- コンソールとして割り当てられたもの ( 例: シリアル線、ローカルビデオカード )
the src/sys/arch/x86/include/bootinfo.h file holds the complete list of possible values for bootinfo items. bootinfo is similar to the mis, although the information it includes is slightly different and, in some specific cases, more complete. in fact, this was one of the main headaches when adapting the netbsd kernel to support multiboot.
src/sys/arch/x86/include/bootinfo.h ファイルは、bootinfo アイテムとして利用可能な完璧なリストを持っている。bootinfo は MIS に似ている。この情報に含まれるものは少し違うが、いくつかの場合においてはまったく完璧だ。実際、これは、NetBSD カーネルがマルチブート対応を追加するときの主な頭痛の種のうちの 1 つであった。
later on, the kernel gets the execution control and proceeds by:
その後、カーネルは実行制御を取得し、以下を処理する:
- storing the boot information (bootinfo or mis) in a safe place. see the native_loader function in src/sys/arch/i386/i386/machdep.c.
- detecting the cpu model in use (e.g., 386, 486, pentium).
- setting up a preliminary page directory and the corresponding page tables to remap the kernel's virtual addresses above 0xc01000000.
- enabling memory paging and jumping to high memory.
- continuing to boot and processing the boot information during its initialization.
- 安全な場所にブート情報( bootinfo または MIS )を保存する。src/sys/arch/i386/i386/machdep.c の native_loader 関数を参照
- 使用している CPU モデルを発見する( 例: 386, 486, pentium )
- 予備のページディレクトリをセットアップし、整合されたページテーブルをカーネルの仮想アドレス 0xc01000000 以降に再配置する.
- メモリーページングを有効にし、高メモリへジャンプする
- 引き続きブートし、初期化中のブート情報を処理する
one tricky thing is that the netbsd kernel runs, by design, at very high memory addresses (0xc0100000 and higher) for efficiency reasons: doing this allows the mapping of the kernel inside the processes' virtual address spaces without interferences. however, as mentioned earlier, the boot loader does not enable paging so it is impossible for it to put the kernel at such high addresses (unless the machine has lots of physical memory, but that is not the idea).
効率化のため{ ???? }、かなり高いメモリアドレス ( 0xc0100000 とかそれ以上 )において、設計により NetBSD カーネルが走るときに 1 つトリッキーなことがある。干渉がないカーネル内のプロセスの仮想アドレス領域を配置することを許可している。しかし、先に触れたように、ブートローダーはページングを有効にしない だから 高アドレスのようなところ( マシンがたくさんの物理メモリを積んでいない場合は例外だ )にカーネルを配置するのが不可能である。
the elf file format resolves this issue: each section in the image (text, data, bss, and so on) specifies which address is its starting virtual address, but also specifies its physical load address. the netbsd kernel's linker script takes advantage of this to generate an elf image mapped over 0xc0100000 but placed at the 0x00100000 physical address. note that the address is not 0x00000000 to ensure that the kernel does not overwrite any bios code and/or data stored below the first megabyte (the only address space accessible from real mode) when loaded.
ELF ファイルフォーマットは以下の問題を解決する。イメージ内の各セクション(text、data、bss とかいろいろ)は、アドレスが仮想アドレスから開始するように指定する。物理ロードアドレスも指定する。NetBSD カーネルのリンカースクリプトは、0x00100000 の物理アドレスに配置されている ELF イメージを 0xc0100000 以降に配置することについて優位性がある。なお、アドレスは 0x00000000 ではなく、カーネルがロード時に、あらゆる BIOS コードや最初の 1 メガバイトより下にあるデータストアを上書きしない( このアドレス領域だけはリアルモードからアクセスされる ) ことを保証する。
before paging is enabled, the kernel code is critical because it must be careful to not use the raw addresses generated by the linker (as they point to unavailable memory positions). the reloc macro resolves this by converting a given virtual address to its corresponding physical location. fortunately, once paging works, no more problems appear and this is basically a non-issue.
ページングが有効になる前はカーネルコードはクリティカルである。なぜならばそれはリンカが生成した生アドレス( 無効メモリ位置へのポインタのように )を使わないように注意しなければならないからだ。reloc マクロは、与えられた仮想アドレスから、一致する物理位置へ変換することによりこれを解決する。幸運にも、一度ページングが作用すれば、これ以上問題は現れないし、これは基本的には問題ではないのである。
making netbsd multiboot-compliant ( NetBSD をマルチブート対応にする )
due to some limitations in the native netbsd boot loader, i needed to boot netbsd using grub in a spare machine i used for kernel testing. when doing so, i found that native netbsd boot support in grub is very rudimentary, and even broken in several situations. for example, it does not set up the ksyms correctly, so ddb(4) backtraces are very difficult to understand. in addition, the upstream code does not support passing boot-time options to the kernel, but fortunately pkgsrc includes some local patches to resolve this issue.
NetBSD のネイティブなブートローダーにはいくつか制限がある。NetBSD を GRUB を使ってブートさせるために予備のマシンを用意し、カーネルをテストした。それをおこなったところ、GRUB 対応の NetBSD のネイティブなブート( ローダー? ) は、とても原始的であることが分かり、いくつかの場面でよく壊れた。たとえば、ブートローダーは ksysms を正しくセットアップしないので ddb(4) のバックトレースを理解するのにものすごく苦労する。さらに、アップストリームコード{ 最新のコード?? } はカーネルへのブート時オプションに対応していない。しかし幸運にもこの問題を解決するためのいくつかのローカルパッチが pkgsrc に含まれている。
there were two different solutions to my problems: fix grub to include full support for native netbsd boots or make the netbsd kernel multiboot-compliant. i chose the latter because i personally like the idea behind multiboot: it is more in the line of defining an abstract interface between two different system components. more importantly, though, is that changing the netbsd kernel alone has the advantage that the code in grub will not rot: the grub developers are the main developers of the multiboot specification and, because it has no netbsd-specific bits in it, they don't need to have a netbsd system available to ensure it is supported.
私の問題には 2 つの異なった解決策がある。GRUB をネイティブな NetBSD ブートローダーに完全に対応させるか、NetBSD カーネルをマルチブート対応させるかだ。私は後者を選んだ。なぜなら、前述のマルチブートのアイデアが個人的には好きだからだ。それは、2 つの異なるシステムコンポーネント間の抽象インターフェースにもっとコードを定義するものだ。もっと重要なことは、NetBSD カーネル単体を変更することは GRUB にあるコード対する優位性を無くすことはないだろうということだ。GRUB 開発者はマルチブート仕様の主な開発者であり、それゆえ、NetBSD の仕様には踏み込んでいない。彼らは NetBSD 対応を保証するために NetBSD システムを有効にする必要がないのである。{ NetBSD に特別に対応する必要がない、という感じか???? }
the first step was to define some high-level data structures to represent and manage the mh and the mis from within the kernel - something easy thanks to the detailed documentation about them. the results are in src/sys/arch/i386/include/multiboot.h.
最初のステップは、カーネル内の MH と MIS を表現したり管理するためのいくつかの高レベルデータ構造を定義することだった。それらについての詳細なドキュメントがあるのはありがたい。成果物は src/sys/arch/i386/include/multiboot.h にある。
then, the obvious move was to add an mh to the kernel so that grub could recognize it. to ensure that it was within the first 8kb of the image, i added it in the text section of src/sys/arch/i386/i386/locore.s alongside the kernel's entry point.
その後、明確な移動はカーネルに MH を追加したことだ。なので、GRUB は見分けが出来るようになった。それを保証するために、イメージの最初の 8 KB に収めた。カーネルのエントリーポイントの近くにある src/sys/arch/i386/i386/locore.s の text セクションに追加した。
this was not easy at all: the kernel's linker script had a bug that made the sections' physical addresses point to the virtual addresses. this forced me to use the address fields in the mh to indicate where to load the file, but grub was not honoring them for elf files. i had to come up with a fix for grub until a fellow developer, pavel cahyna, fixed the problem from its root: he rewrote the linker script to generate the appropriate physical addresses. nowadays, those extra fields in the mh are not used, and a mainstream grub image (distributed in virtually any gnu/linux distribution) can boot a netbsd kernel.
これは、以下のすべてにおいて簡単ではなかった。カーネルのリンカスクリプトには、セクションの物理アドレスが仮想アドレスを指すというバグがあった。これは私に、ファイルをロードするところでの MH のアドレス領域を使うことを強要した{???????????}。しかし GRUB はそれらの ELF 領域を受け入れていなかった {???????????}。GRUB の特別開発者 pavel cahyna がそれの root からの問題を適用するまでの間は GRUB を修正しておくことにした。彼は適切な物理アドレスを生成するためにリンカ―スクリプトを書き直した。今日では、それらの MH の特別領域は使われていないし、主流の GRUB イメージでは NetBSD カーネルがブート出来るようになっている( あらゆる仮想 GNU/Linux 配布物内の配布物においては )。
with the kernel recognized as a multiboot binary, i had to add the necessary code to parse the mis during boot and convert it to the native bootinfo format to minimize changes in the overall kernel. keep in mind that i was just adding another entry point to the kernel, not removing the old one, so both needed to coexist. this was tricky because of the virtual address space change that happens during bootstrap, as explained earlier: some mis handling needed to happen before the kernel enabled paging to avoid corrupting important information (basically, the ksyms).
マルチブートバイナリとして認められたカーネルにおいて、ブートしている間の MIS を解析し、カーネル全体を多少変更しネイティブな bootinfo 形式へ変換に必要なコードを追加した。私はカーネルに他のエントリポイントを追加しただけであり、エントリポイントを置き換えたわけではない。それらは同時に存在する必要があるのだ。ということを覚えておいてほしい。これはトリッキーだ。なぜならば前述したように、ブートストラップの間に仮想アドレス空間を変更するからだ。いくつかの MIS ハンドリングは、重要な情報( 基本的には ksysms )の欠落を回避するためのカーネル有効ページングが発生する前に必要となるからだ。
the c code that handles this is rather delicate and, therefore, i kept it as short as possible. once the kernel has enabled paging, the real mis parsing is done and the kernel continues its boot procedure. you can see all of this in the src/sys/arch/i386/i386/multiboot.c source file.
ハンドルする C コードは、これは多少 微妙であるんだが、なるべく短く出来るように保った。一度カーネルが有効ページングしたら、リアル MIS 解析は完了し、カーネルは自身のブート手続きを続ける。src/sys/arch/i386/i386/multiboot.c ソースファイルで全てを見ることができる。
at last, i would like to comment on another area that was difficult to manage. the native boot loader loads the netbsd kernel and stores it in memory following a specific memory layout: the kernel is first, followed by an integer that registers how many symbols the kernel has, followed by a minimal elf image that contains the kernel's symbol and string tables. when using grub, these tables load in different and unpredictable locations.
最後に、私は管理するのが難しい他の領域についてコメントしたい。ネイティブブートローダーは、NetBSD カーネルをロードし、以下に示すメモリ配置へ設置する。カーネルは最初にある。次に、カーネルがどれだけのシンボルを持っているかの整数値がある。次に、カーネルシンボルと文字列テーブルを含んだ最低限の ELF イメージがある。GRUB を使う場合、これらのテーブルは異なる場所、予測できない場所からロードされる。
a first step in resolving this problem was to reserve some space in the kernel to copy the symbols table to the appropriate place on the fly, but this proved to be a very ugly hack. a recent fix moved the symbols table to just after the kernel (taking care not to overwrite it or other important information during the move). the kernel also has a specific function to initialize the ksyms global table based on a memory region (not necessarily a complete elf image). you can see this in the ksyms_init_explicit function defined in src/sys/kern/kern_ksyms.c.
この問題を解決するための最初の手順は、カーネルがシンボルテーブルを適切な場所へダイレクトにコピーできるように、いくらかの領域を予約することだ。しかしこのやりかたは実に酷い hack だ。関連した fix はシンボルテーブルを、ちょうどカーネルの後ろへ移動する( 移動させている間にカーネルや重要な情報を上書きしないように注意 )。カーネルは、メモリ領域をベースにした ksyms グローバルテーブル( 必ずしも ELF イメージではない )を初期化するための特別な関数も持っている。ksyms_init_explicit 関数の定義は src/sys/kern/kern_ksyms.c で見れる。
conclusion ( 終わりに )
if all operating systems supported the multiboot specification, users would be happier than they are now: a very advanced boot loader supporting all operating systems would most likely exist, and its installation could be trivial. plus, these users would not need to care about the installation of an os disabling another os.
すべてのオペレーティングシステムがマルチブート対応したならば、利用者はいまよりも幸せになるだろう。ブートローダーがかなり進歩してすべてのオペレーティングシステムに対応ことがもっともありがたいことである。そしてそれは、インストール作業が取るに足らないことになるだろう。さらに、これらの利用者は、OS インストール作業で他の OS を無効にすることに注意する必要がなくなるだろう。
personally, i found the process of making the netbsd kernel multiboot-compliant to be a very interesting and instructive task. furthermore, because almost all linux distributions nowadays install grub by default, it is now a lot easier to set up a dual-boot machine with both linux and netbsd. further steps involve splitting the kernel in two different sections within the elf binary in order to map each of them at separate virtual addresses. this could simplify some of the issues that arise in the code that runs before paging is enabled.
個人的にはマルチブート対応 NetBSD カーネルを作成する作業はとても面白かったし、タメになった。そのうえ、いまどきのほとんどすべての Linux ディストリビューションは既定で GRUB をインストールするので、今や Linux と NetBSD の両方でデュアルブートマシンをセットアップすることはとても簡単である。さらに先のステップとしては、されたカーネル、分割された仮想アドレスの各々へマップするための ELF バイナリ内の 2 つの異なるセクションで、カーネルを分割することだ。これはページングが有効になる前に走るコードで発生するいくつかのシンプルな課題で出来る。
now it is your turn to adapt your favorite operating system to this protocol and attempt to get your modifications into the mainstream sources!
次はあなたの番だ。このプロトコルにあなたの好きなオペレーティングシステムを適合させ、あなたの改造をメインストリームのソースにも試してみよう。
julio m. merino vidal studies computer science at the fib faculty in barcelona, spain.
2011-06-18 :-)
_ 午後
1500 アニメ
_ 夜
1700 買い物
1930 RR7 ジャクチョーさんルームでリバースチャージ縛りレース。こういうときじゃないと乗れない
2100 飯
2230 RR7 再びジャクチョーさんルーム。チームバトルで STARNOSE v.s. HIJACK(ドルアーガ)
2500 RR7 終了
2011-06-19 :-)
_ 午前
0900 起床
_ 日曜日デザインパターン
1 歩も家から出ていない
_ Old Nabble - PR/44939 CVS commit: pkgsrc/mail/quickml
Based on PR#44939 by Susumu Miwa. Modified by Makoto Fujiwawa and me in pkgsrc-wip.
入ったも
MAINTAINER を pkgsrc-users@NetBSD.org にするというチキンですが－
2011-06-20 :-(
_ 午後
1300 テスト
_ 夜
1700 残業アワー
1730 俺達の戦いはこれからだ
2000 退勤
2200 飯。ブリの照り焼き
2230 ジャンプ読むなど
2300 NHK 総合 ディープピープル「時代劇をいろどる殺陣（たて）」 録画消化
2330 NHK 総合 緑のカーテンの作り方録画消化
_ お前らそろそろまどか☆マギカローソンだけどどうするの？しぬの？
_ というかむしろ UNIX リハビリしている
4894713195
2011-06-23 :-(
2011-06-24 :-(
_ ,
んもんも
_ [Python][グラフ]Python でグラフ書く候補
- Pychart
- 他モジュールが不要
- 古い( 10/25/2002 )
- matplotlib
- ナウい?
- 要 NumPy
- Gnuplot.py
- Python Google Chart
- 他モジュールが不要
- 要 Google Chart へのアクセス
2011-06-25 :-)
_ 午前
1000 起床 || 部屋掃除
_ [リッジレーサー7]リッジレーサー7 ARC 2011 水無月GP
今年もやるぜ ARC
今回は新たに came_yaroh がデビュー。始めたばかりだからまだニトロポイントを身につけてないけど、基礎力はじゅうぶん鍛えられてるのでコツをつかめばあのひとはバケモノになる。
- ANSΩkeyaki 177
- REDOGRE 136
- SOLARE 136
- GREENOGRE 135
- Locus 95
- MEDAL 90
- ANSΩmiwarin 89
- SYOURYU 48
- ANSΩ三嶋出雲 47
- ANSΩ八雲藍 24
- ANSΩ黒豹 20
- かず 12
- came_yaroh 1
- 走行距離 97656 km
- RSGP 進行度 100.0 %
- 名声 26678 FP
- オンラインバトル勝利数 1242/4465
2011-06-26 :-)
2011-06-27 :-(
2011-06-28 :-(
2011-06-29 :-(
_ 午後
1300 テスト
_ ルミナス [昨日はどうもありがとうございました。 「紅龍＠ガーネット」です。 またお会いできたら勝負しましょう（＾－＾） ..]
_ みわ [おお。初めましてというかレースお疲れ様でした。 いや私もベースクルーザーはあまり乗れないので、ミスって押してもらっ..]