Загрузочный каталог

В середине декабря 2002 года в систему была добавлена новая характеристика, заменяющая устаревший файл загрузки #//boot на загрузочный каталог и, взамен двоичного файла, требующего компиляции, появился сценарий.

В конфигурационном файле ядра появился новый раздел под названием «bootdir», который содержит список файлов, заменяющих #//boot. В каталоге #/больше нет двоичных файлов.

Типичный раздел bootdir выглядит примерно вот так:

bootdir
	bootpcdisk.out boot
	/386/bin/ip/ipconfig
	/386/bin/auth/factotum
	/386/bin/disk/kfs
	/386/bin/cfs

который сообщает, что каталог /boot содержит четыре файла: boot, ipconfig, factotum, kfs и cfs, скопированные из указанных источников.

Все ядра имеют специальный файл boot$CONF.out, указывающий на загрузочные файлы в /boot.

Теперь, когда все находится в /boot, для всех ядер был изменен initcode; /boot/boot изменен для выполнения /boot/ipconfig (взамен /ipconfig), и т.п. Наконец, изменениям подвергся auth_getkey, теперь для работы с любым типом ядра он сперва выполняет поиск /factotum, а затем /boot/factotum.

Загрузочный файл /386/bin/ip/ipconfig переключается на _386_bin_ip_ipconfig.root.s, а затем _386_bin_ip_ipconfig.root.8. Немного уродливое имя, ноmk нормально обрабатывает его. Одно неудачное последствие большого имени — это то, что _386_bin_auth_factotum.root.s является слишком длинным для соединения с текущими файловыми серверами. Вы конечно можете использовать сервер lnfs для работы, но я бы не стал. Для устранения зависимости отlnfs(4) при постройке ядер в файл portmkfile было добавлено новое правило, которое копирует factotum и ipconfig в factotum.hack и ipconfig.hack. После этого раздел bootdir выглядит примерно так:

bootdir
	bootpcdisk.out boot
	ipconfig.hack ipconfig
	factotum.hack factotum
	/386/bin/disk/kfs
	/386/bin/cfs

грустно (!), но проблема устраняется при использовании именно длинных имен файлов.

Pc initcode также был изменен, поскольку до этого он обычно делал:

exec("/boot", ["boot", 0]);

на ассемблере (pc/initcode.s), сейчас он делает:

open("#c/cons", OREAD);
open("#c/cons", OWRITE);
open("#c/cons", OWRITE);
bind("#c", "/dev", MAFTER);
bind("#ec", "/env", MAFTER);
bind("#e", "/env", MCREATE|MAFTER);
bind("#s", "/srv", MREPL|MCREATE);
execl("/boot/boot", "/boot/boot", 0);

на С (port/initcode.c). Указатель устанавливает достаточное пространство имен, когда /boot/boot может быть сценарием оболочки. В конечном счете другие архитектуры также должны изменятся.

Другим примером является ядро под названием pcext, построенное мною однажды ночью. Оно использует rx и trampoline для соединения через шлюз машины Plan 9 к корневому файловому серверу. В нем используется такой bootdir:

bootdir
	bootext boot
	/386/bin/rc
	/rc/lib/rcmain
	/386/bin/bind
	/386/bin/cat
	/386/bin/cp
	/386/bin/echo
	/386/bin/mount
	/386/bin/sleep
	factotum.hack factotum
	/386/bin/ip/ipconfig
	/386/bin/cfs
	/386/bin/aux/srvthru

(также не требует lnfs для постройки).

Srvthru — очевидная в этих случаях программа: она подключается к rx, производит аутентификацию, запускает trampoline на настоящем файловом сервере, а затем подключает cfs к соединению.

Указателем является сценарий оболочки bootext, существенно упрощающий работу:

#!/boot/rc -m /boot/rcmain

cd /boot
cp '#r/rtc' '#c/time'
bind -a /boot /bin
bind -a '#I' /net
bind -a '#l0' /net
bind -a '#S' /dev
bind '#p' /proc
bind '#d' /fd
bind -a /boot /
ipconfig
echo 'authdom=cs.bell-labs.com auth=204.178.31.3' >>/net/ndb
factotum -sfactotum -u -a 204.178.31.3
cargs=()
if(~ $#cfs 1 && ! ~ $cfs off)
	cargs=(-c $cfs)
srvthru $cargs tcp!204.178.31.2!17009 il!emelie!9fs boot emelie
mount -c /srv/boot /root
bind -ac /root /
bind -c /root/mnt /mnt
mount -a '#s/factotum' /mnt
rootdir=/root
rootspec=
/386/init -t
/boot/rc -m/boot/rcmain -i	# in case init fails

Он заботится обо всем, что традиционно делает /boot, используя srvthru как путь установки /srv/boot (а также /srv/emelie).

Загрузочный каталог

Fan Feed