Bulgarian Plan 9 resources -- Български План 9 ресурси

This page is UTF-8 encoded

This is a rather free-form bulgarian translation of "Plan 9 from Bell Labs". Courtesy of L. Ionkov.

Това е сравнително свободен превод на документа "Plan 9 from Bell Labs". Оригиналния превод е на Лъчезар Йонков, формат и допълнителна обработка на Андрей Мирчовски. За допълнителна документация относно План 9 вижте оригиналната страницa на bell-labs (ако желаете да направите превод на някой от документите там пишете ми -- ще сложа вашия превод тук).

Тези от вас които нямат проблеми с руския език (май английския вече замести руския като модерен втори език) можете да погледнете руския превод на същите документи на страницата на Андрей Кухар тук.

План 9 от Bell-Labs

I. Основни идеи

Всички системни обекти са представени като именувани файлове. Операциите с обектите се извършват чрез четене и запис в тези файлове.
Всеки процес има независима от останалите структура на файловата система (private namespace). Процеса може да променя тази структура без да има изключителни права.

II. Namespace и Файлов Сървър

Системните извиквания за работа с файловата структура са mount bind and unmount.

Системното извикване mount добавя (монтира) дърво сервирано от файлов сървър в текущия namespace. Като връзка към файловия сървър, ядрото получава файлов дескриптор. Комуникацията м/у ядрото и сървър-а се извършва чрез писане и четене в този дескриптор. Протокола на съобщенията се нарича 9P и позволява обхождане на дървото, четене/запис на съдържанието на файловете и т.н.

Системното извикване bind позволява монтирането на част от вече съществуващия namespace на друго място.

Plan9 позволява при монтиране, предишното съдържание на директорията да продължи да е достъпно. При извикване на mount или bind, може да се укаже дали новото дърво да се "залепи" най-отпред, най-отзад, или напълно да замени съдържанието на директорията в която се монтира. При обхождане на директориите, всички монтирани в нея дървета се обхождат в съответния ред.

Пример 1: В Plan9 променливата от обкръжението PATH не се използва. Вместо това всички директории до които потребителя иска да има достъп за изплнение, се монтират в /bin.
Пример 2: Ако някои процес иска да чете съобщения от мишката, отваря /dev/mouse. В случай че не е стартиран windowing system, процеса чете от истинското (предоставено от ядрото) устройство. В случай че процеса е стартиран в прозорец, window manager-a се е погрижил файла /dev/mouse да е заменен с друг, чрез който процеса получава само събитията, станали в рамките на прозореца на процеса. Нещо подобно на /dev/tty в Unix, но обобщено и реализирано за всички устройства (клавиатура, мишка, рисуване на екрана (и графика)).

III. Работа в мрежа

Архитектурата на Plan9 показва предимствата си много добре при работа в мрежа. Простотата на връзката м/у ядро и файлов сървър прави много лесно отдалеченото използване на файлови сървъри. Използвайки командите import и cpu потребителя може да забрави къде се записват файловете му и на коя машина се изпълняват процесите му.

Командата import позволява на потребителя да монтира в текущия namespace част от namespace-a на отдалечена машина. Обикновено потребителя работи на бездисков компютър, използвайки файловата система предоствена от файлов сървър.

Командата cpu е по-интересна. Да предположим че потребителя има изградена някаква файлова структура на локалния си компютър (монтирайки различни локални и отдалечени файлови сървъри). В един момент потребителя решава че локалния му компютър е много бавен за програмата която иска да ползва. Пише

cpu veryfastserver

и се озовава на ужасно бързия сървър veryfastserver, запазвайки напълно файловата йерархия която е виждал на терминала. За него единственото което се е променило е скоростта на изпълнение на програмата. Да предположим че програмата е написана така, че докато изпълнява много бавната си задача, се опитва да забавлява потребителя свирейки нещо на звуковата карта. Тъй като файловата йерархия е същата като на локалния компютър, устройството /dev/audio сочи към звуковата карта на локалния компютър, а не към тази на сървъра. И потребителя ще чуе мелодията в неговите слушалки, вместо да стряска другите потребители седящи близо до сървър-а :). Или пък ако потребителя си е конфигурирал мрежата по специален начин, напр. да рутира през друг рутер, програмата ще използва неговата конфигурация на локалната машина, въпреки че се изпълнява на сървър-а на които има друга конфигурация на мрежата.

IV. Примери за файлови сървъри

Всичко в Plan9 се вижда като сбор от файлове -- ethernet карта, IP протокол, процес и т.н. Тъй като не всички компютри в мрежата са с еднакви процесори, създателите на ОС-а са решили (и спазват до голяма степен) да ползват текстови команди за управление на системните обекти. Така ако трябва да се изпрати параметър 20, той се записва като низ "20" вместо като поредица от байтове с някакъв вид endianness. На пръв поглед това решение не е удачно, но то има някои предимства които не се забелязват веднага.

Ще се опитам да покажа как са представени някои системни обекти и какви са предимствата от такова представяне:

Процес:
Предстаявянето на процеса като сбор от файлове е подобно на това в Unix. За всеки процес в /proc има директория с име pid-a на процеса. Едно от различията които си заслужава да спомена е файла ctl. Писането на текстови съобщения в този файл, променя различни параметри на процеса. Например
stop спира процеса start възстановява изпълнението на процеса kill убива процеса pri n сменя приоритета на процеса wire n "залепя" процеса към n-тия процесор
Всичката информация която дебъгер-а ползва за процеса, се намира в /proc/XXX. По този начин отдалеченото дебъгване на процес на машината X от машината Y се състои от импортирането на файловата система /proc на машината X някаде във файловата система на Y и указването на мястото на монтиране на дебъгера.
IP интерфейс:
Структурата на файловия сървър представящ IP протокола изглежда така:
```
	/net/ipifc/clone 
	/net/ipifc/stat 
	/net/ipifc/N 
	/net/ipifc/N/status
	/net/ipifc/N/ctl
```
където N е число представящо номера на интерфейса. За да се създаде нов интерфейс, се отваря файла /net/ipifc/clone. Това създава нова поддиректория и връща номера на новия интерфейс. Писането във файла /net/ipifc/N/ctl конфигурира интерфейс-а. Например за да се "върже" интерфейса 3 към втората ethernet карта, се извиква:
```
	$ echo bind ether /net/ether1 > /net/ipifc/3/ctl
```
/net/ether1 е пътя до директорията, описваща втората Ethernet карта. За да се зададат локални IP адреси на интерфейса се извиква:
```
	$ echo add 192.168.33.1 255.255.255.0 > /net/ipifc/3/ctl
```
Разбира се съществуват и команди които вършат същата работа, но е приятно да знаеш че можеш да конфигурираш всичко само със shell script и echo ;)
TCP стек
Структурата на файловия сървър представящ TCP стека изглежда така:
```
	/net/tcp/clone 
	/net/tcp/stats 
	/net/tcp/N 
	/net/tcp/N/data 
	/net/tcp/N/ctl
	/net/tcp/N/listen
```
Да предположим че искаме да отворим TCP връзка до компютъра с адрес 192.168.10.1 на порт 22:
```
	$ cat /net/tcp/clone 5
```
създава нова връзка която може да се контролира чрез файловете в /net/tcp/5.
```
	$ echo conect 192.168.10.1!22 > /net/tcp/5/ctl $
```
След тази команда, четенето и записа във файла /net/tcp/5/data осъществява четене и запис по TCP връзката.
Отново, има C функции (dial()), които вършат черната работа вместо програмиста.

V. Някои произволни факти (не всички положителни)

В Plan9 няма суперпотребител (root).

Няма symbolic links -- bind върши работата по-добре.

Няма динамични библиотеки

Файловия сървър обикновено е определен компютър, които не върши нищо друго освен да сервира файлове. На него не могат да се пускат никакви процеси, ядрото му е специално и т.н. Върши само едно нещо, но го върши добре ;). Интересно е, че всяка вечер файловия сървър прави нещо като backup на файловата система. Всички файлове от 5 септември 1999 могат да се прочетат от директорията /n/dump/1999/0905. Това е нещо като poor man's versioning system, който в действителност върши доста добра работа -- обикновено човек помни какво е правил последния ден ...

Last Modified: May 31 2003
mirtchovski at gmail