1998/10/27
	ソースツリーにおける各ディレクトリの管理分担


					任天堂株式会社 開発３部 橋田貴之

1. ソースツリーのそれぞれのディレクトリの意味


admin:		ソースツリー管理用のツールやドキュメントが入っています。
apps:		リリースしていないものも含んだ、サンプルプログラム
apps.released:	apps のうち、リリースしているサンプル
as:		グラフィックデータを C で表現したもの(を途中までコンパ
		イルした中間ファイル？)
assets:		サウンド波形データ(リリースしているもの、および 64DD 
		の DDROM に入っているもの)や 64DD のフォントなど
build:		メジャーリリース作成時に使用する
debugger:	デバッガに関連するもの(開発ボード時代のもの)
diags:		開発ボードの検査プログラム
doc:		種々のドキュメント
gdb:		N64 用の gdb
html:		man page の html バージョン(現在は業務部内で管理してい
		るため、使用していない)。
include:	リリースしているヘッダファイルが格納されているディレク
		トリ
kern:		開発ボードの Indy 用デバドラ等
lib:		Indy 側のライブラリ、IPL 等
libleo:		64DD のライブラリ
libnaudio:	n_audio のライブラリ
libultra:	libultra
man:		マンページおよび、メジャーリリースのリリースノート等。
		このディレクトリの内、現在使用しているのは下記のファイ
		ルのみ。
	README.release(/usr/src/PR/ 下のディレクトリの説明)
	relnotes_jp(ultra のリリースノート)
	relnotes_jp.64dd(64dd のリリースノート)
	relnotes_jp.naudio(naudio のリリースノート)
rdpsim:		RDP のシミュレータ
rdpsim2:	同上
ritest:		何かのテスト用ベリログソース
rspasm:		RSP のアセンブラ
rspasm1201:	RSP のアセンブラ
rspcode:	マイクロコードのソース
rspsim:		RSP のシミュレータ
tools:		ツール関係(makerom や n64mdisk 等)

下記のディレクトリは、パッチブランチにのみ存在する(「パッチブランチ」
については、このドキュメントの最後に記載されている「用語説明」を参照)
patch:		パッチ作成用のツール(SGI, PC 共)、リリースしたパッチ等 


2. include/ と libultra/ 以外の各ディレクトリの管理分担


招布が変更してよいもの：

as/
assets/
build/
debugger/
diags/
doc/
gdb/
html/
kern/
lib/	(ただし、IPL4 のソースを除く)
libnaudio/
man/
patch/
ritest/
tools/	(ただし、64DD関連のasccode, byte2lba, calcncc, leowrite, n64mdisk,
	ramstart を除く)



開発３部が変更してよいもの：

admin/
lib/BringupBoot/IPL4
libleo/
tools/asccode, byte2lba, calcncc, leowrite, n64mdisk, ramstart
apps.released/voice, reboot, ddspgame


業務部の管轄下にあるもの：
(これらは、業務部の管轄において、変更等を行なう)
rdpsim/
rdpsim2/
rspasm/
rspasm1201/
rspcode/
rspsim/



注意を要するもの：
apps/	
apps.released/
(apps.released はマスターソースの中で、apps のシンボリックリンクになっ
ているため、apps の方を通常変更する。apps.released は apps を変更する
と自動的に変更される。)

このディレクトリ下のサンプルの内、
voice/, reboot/, ddspgame/ は３部の管理。

それ以外は招布の管理。

新しいサンプルの追加は自由。追加したあと連絡をする。



3. libultra/ の管理分担

libultra/monegi		招布が変更する
libultra/nintendo	３部が変更する
libultra/shared		変更の際は相談した上で、monegi か nintendo の
			ディレクトリに移してから変更する



○現在の monegi, nintendo, shared ディレクトリの構成：

    monegi--------------------------------------------------------
	ai/		AI の関数(ai の status register を読む等)
	audio/		オーディオライブラリ
	cache/		キャッシュ操作関係
	cont/		コントローラ関係
	convert/	仮想アドレス←→物理アドレス変換
	debug/		assert, profile 等
	gio/		gio バスをアクセスする関数
	gt/		ターボグラフィックスユーティリティ
	gu/		グラフィックスユーティリティ
	host/		hostio 関連
	libc/		ストリング関数、printf 等
	log/		ロギング関数
	message/	メッセージ関連関数
	rdp/		rdp の io 関連関数(status register を読む等)
	reg/		CPU のレジスター入出力関数
	rg/		リージョン関数
	rmon/		rmon
	rsp/		rsp の io 関連関数(status register を読む等)
	sched/		スケジューラ
	si/		si
	sprite/		スプライトライブラリ
	thread/		スレッド操作関数
	time/		time, timer
	tlb/		TLB 関連関数
	vi/		vi


    nintendo-----------------------------------------------------
	eeprom/		EEPROM アクセス関数
	error/		エラーやフォルトに対応する関数
	exception/	例外ハンドラ等
	pi/		pi, epi
	voice/		音声認識


    shared--------------------------------------------------------
	gbpak/		64GB パック
	motor/		振動パック
	pfs/		コントローラパック
	system/		64OS のイニシャライズ、preNMI 関連等




4. include/ の管理分担
	include の下のディレクトリは、旧 os.h が分割され、上記の 
	monegi, nintendo, shared 下のディレクトリに対応して、

		os_ai.h, os_audio.h, ... 

	といったように細分化されている(新 os.h はこれら細分化されたヘッ
	ダファイルを全てインクルードしている)。したがって、ヘッダファ
	イルがどの会社の担当かどうかは、対応するディレクトリがどうであ
	るかによる。

	例えば、現時点であれば、os_ai.h は招布、os_voice.h は３部、と
	いった具合いになる。

	旧 os_internal.h も細分化されているが、こちらは全部のディレク
	トリに対応したヘッダファイルがあるわけではない。必要になった時
	点で、責任者同士で相談の上、追加していく。

	その他のファイルに関しては、rcp.h のみ３部、その他は招布とする。
	ただし、os.h, os_internal.h は要相談とする。

	まとめると、

	３部が変更してよいもの：
			rcp.h
	相談した上で変更するもの：
			os.h, os_internal.h
	ディレクトリの担当に応じて担当が違うもの：
			os_***.h, os_internal_***.h
	招布が変更して良いもの：
			その他全部



5. PC 版について


PC 版の作成と動作確認は、原則として、SGI 版で変更を行った者が行う。

PC 版には、SGI で作成したファイルそのものを使用できる部分と、SGI 版か
ら移植する必要のある部分がある。

○SGI 版と同じファイルを使用するもの

	以下のものは SGI で作成したものと同じファイルを用いる。ただし、
	PC 版での動作確認は必要となる。

assets/	
include/
lib/BringupBoot/IPL4
libleo/
rspcode/



○SGI 版から変更する必要があるもの

	以下のものは SGI 版で作成したものから変更する必要がある。しか
	し、その変更を最小限に押さえるため、SGI 版作成時から PC 版のこ
	とを考慮に入れ、できるだけ共通で使用できるようにするのが望まし
	い。

apps/		
apps.released/
	SGI 版 とは異なる。ただし、ソースは共通なものがほとんど。違い
	は、各種コンバータが PC に移植されていないため、コンバートされ
	た後の形式でデータを持つようにしていること。Makefile も異なる。
	現在、各サンプルのディレクトリで 'make -f PCmake' を実行すると、
	apps.pc/ に PC 版サンプルが作成されるようなシステムになってい
	る。ただし、reboot のみ未対応。

lib/libultrahost/
	PARTNER-PC 用 HostIO ソース。
	PC 側のライブラリは、現在京都マイコンで管理。今後は？

libultra/
	ソース自体は SGI 版と同じ。Makefile のみ異なる。

tools/
	asccode, byte2lba, calcncc, n64mdisk, ramstart のみが対象。こ
	れ以外は PC では出していない(makerom, makedisk は mild として
	出しているが、mild のソースはソースツリーに入っていない)。
	ソース自体は SGI 版と同じ。Makefile のみ異なる。
	PC 版(386用) gcc でコンパイルする必要がある。
man/relnotes_jp, relnotes_jp.64dd, relnotes_jp.naudio
	メジャーリリース時のリリースノート
man/README.release
	/usr/src/PR/ 下のディレクトリ説明のためのドキュメント

○その他(移植が必要なもの)

	以下のもの（libnaudio/は除く）は、マイクロコードの開発環境であり、
	一般にリリースしているものではないため、PC 版は存在しなくても構わ
	ない。PC 版の移植を進めるかどうかは、業務部の管轄。

libnaudio/
rdpsim/
rdpsim2/
rspasm/
rspasm1201/
rspsim/



＊注(用語説明)

ブランチについて：
	CVS には、「枝分かれ」を管理する機能がある。例えば、リビジョン 
	1.5 のファイルをリリース後、内部的に 1.7 までバージョンが上がっ
	ていたとする(つまり、リリース物の最新は 1.5 だが、内部的には機
	能拡張などで、すでに 1.7 になっているとする)。ここで、1.5 と 
	1.7 共通のバグが発見された場合を考える。1.7 の方にはバグをあて、
	これを 1.8 としてツリーに組み入れればよい。では、1.5 にバグを
	あてたものはどう管理していくか？という問題が生じる。これを解決
	するのが「枝分かれ」の機能。このファイルのリビジョンは 1.5 で
	「枝分かれ」をしていると考える。1.5 をバグ修正したものを「枝」
	として 1.5.2.1 として管理し、以降、このファイルを修正すると、
	リビジョン番号は 1.5.2.2, 1.5.2.3,... と進んでいく。つまり、こ
	の時点で、このファイルは 1.8 という「幹」上のリビジョンと、
	1.5.2.1 という 1.5 から派生した「枝(ブランチ)」上のリビジョン
	の二つが、最新として存在することになる。

パッチブランチ：
	ソースツリーには 2.0I から派生した、大きな「ブランチ」が存在す
	る。日常のソースツリーの変更は「幹」に対して行なうが、パッチを
	リリースする際は、「幹」に加えた変更からリリースするものだけを
	取出し、改めて「ブランチ」に組み込んだ上でリリースする。こうす
	ることによって、開発者がパッチをあてたあとの環境をソースツリー
	上で作り出すことができる。(「幹」上では、リリースしていない変
	更を加えたりしているため、ソースツリーの環境と開発者のパッチを
	あてたあとの環境は異なってしまう。)
	この 2.0I から派生した「ブランチ」を「パッチブランチ」という。