diff --git a/ru_RU.KOI8-R/books/handbook/authors.ent b/ru_RU.KOI8-R/books/handbook/authors.ent deleted file mode 100644 index daf5d6e809..0000000000 --- a/ru_RU.KOI8-R/books/handbook/authors.ent +++ /dev/null @@ -1,468 +0,0 @@ - - -abial@FreeBSD.org"> - -ache@FreeBSD.org"> - -adam@FreeBSD.org"> - -ade@FreeBSD.org"> - -alc@FreeBSD.org"> - -alex@FreeBSD.org"> - -alfred@FreeBSD.org"> - -amurai@FreeBSD.org"> - -andreas@FreeBSD.org"> - -andy@FreeBSD.org"> - -archie@FreeBSD.org"> - -asami@FreeBSD.org"> - -asmodai@FreeBSD.org"> - -awebster@pubnix.net"> - -bde@FreeBSD.org"> - -billf@FreeBSD.org"> - -bp@FreeBSD.org"> - -brandon@FreeBSD.org"> - -brian@FreeBSD.org"> - -bsd@FreeBSD.org"> - -cawimm@FreeBSD.org"> - -cg@FreeBSD.org"> - -charnier@FreeBSD.org"> - -chris@FreeBSD.org"> - -chuckr@glue.umd.edu"> - -chuckr@FreeBSD.org"> - -cpiazza@FreeBSD.org"> - -cracauer@FreeBSD.org"> - -csgr@FreeBSD.org"> - -cwt@FreeBSD.org"> - -dan@FreeBSD.org"> - -danny@FreeBSD.org"> - -darrenr@FreeBSD.org"> - -davidn@blaze.net.au"> - -dbaker@FreeBSD.org"> - -dburr@FreeBSD.org"> - -dcs@FreeBSD.org"> - -deischen@FreeBSD.org"> - -des@FreeBSD.org"> - -dfr@FreeBSD.org"> - -dg@FreeBSD.org"> - -dick@FreeBSD.org"> - -dillon@FreeBSD.org"> - -dima@FreeBSD.org"> - -dirk@FreeBSD.org"> - -Dirk.vanGulik@jrc.it"> - -dt@FreeBSD.org"> - -dufault@FreeBSD.org"> - -dwhite@FreeBSD.org"> - -dyson@FreeBSD.org"> - -eivind@FreeBSD.org"> - -ejc@FreeBSD.org"> - -erich@FreeBSD.org"> - -faq@FreeBSD.org"> - -fenner@FreeBSD.org"> - -flathill@FreeBSD.org"> - -foxfair@FreeBSD.org"> - -fsmp@FreeBSD.org"> - -gallatin@FreeBSD.org"> - -gclarkii@FreeBSD.org"> - -gehenna@FreeBSD.org"> - -gena@NetVision.net.il"> - -ghelmer@cs.iastate.edu"> - -gibbs@FreeBSD.org"> - -gioria@FreeBSD.org"> - -gj@FreeBSD.org"> - -gpalmer@FreeBSD.org"> - -graichen@FreeBSD.org"> - -green@FreeBSD.org"> - -grog@FreeBSD.org"> - -groudier@club-internet.fr"> - -gryphon@healer.com"> - -gsutter@FreeBSD.org"> - -guido@FreeBSD.org"> - -hanai@FreeBSD.org"> - -handy@sxt4.physics.montana.edu"> - -roger@freebsd.org"> - -helbig@FreeBSD.org"> - -hm@FreeBSD.org"> - -hoek@FreeBSD.org"> - -hosokawa@FreeBSD.org"> - -hsu@FreeBSD.org"> - -imp@FreeBSD.org"> - -imura@FreeBSD.org"> - -itojun@itojun.org"> - -iwasaki@FreeBSD.org"> - -jasone@FreeBSD.org"> - -jb@cimlogic.com.au"> - -jdp@FreeBSD.org"> - -jedgar@FreeBSD.org"> - -jehamby@lightside.com"> - -jesusr@FreeBSD.org"> - -jfieber@FreeBSD.org"> - -jfitz@FreeBSD.org"> - -jhay@FreeBSD.org"> - -jhb@FreeBSD.org"> - -jhs@FreeBSD.org"> - -jim@FreeBSD.org"> - -jkh@FreeBSD.org"> - -jkoshy@FreeBSD.org"> - -jlemon@FreeBSD.org"> - -john@starfire.MN.ORG"> - -jlrobin@FreeBSD.org"> - -jmacd@FreeBSD.org"> - -jmas@FreeBSD.org"> - -jmb@FreeBSD.org"> - -jmg@FreeBSD.org"> - -jmz@FreeBSD.org"> - -joe@FreeBSD.org"> - -joerg@FreeBSD.org"> - -john@FreeBSD.org"> - -jraynard@FreeBSD.org"> - -jseger@FreeBSD.org"> - -julian@FreeBSD.org"> - -jvh@FreeBSD.org"> - -karl@FreeBSD.org"> - -kato@FreeBSD.org"> - -kelly@ad1440.net"> - -ken@FreeBSD.org"> - -kevlo@FreeBSD.org"> - -kjc@FreeBSD.org"> - -knu@FreeBSD.org"> - -kris@FreeBSD.org"> - -kuriyama@FreeBSD.org"> - -lars@FreeBSD.org"> - -lile@FreeBSD.org"> - -ljo@FreeBSD.org"> - -luoqi@FreeBSD.org"> - -marcel@FreeBSD.org"> - -markm@FreeBSD.org"> - -martin@FreeBSD.org"> - -max@FreeBSD.org"> - -mark@vmunix.com"> - -mbarkah@FreeBSD.org"> - -mckay@FreeBSD.org"> - -mckusick@FreeBSD.org"> - -md@bsc.no"> - -winter@jurai.net"> - -mharo@FreeBSD.org"> - -mjacob@FreeBSD.org"> - -mks@FreeBSD.org"> - -motoyuki@FreeBSD.org"> - -mph@FreeBSD.org"> - -mpp@FreeBSD.org"> - -msmith@FreeBSD.org"> - -mtaylor@FreeBSD.org"> - -murray@FreeBSD.org"> - -nakai@FreeBSD.org"> - -nate@FreeBSD.org"> - -nbm@FreeBSD.org"> - -nectar@FreeBSD.org"> - -newton@FreeBSD.org"> - -n_hibma@FreeBSD.org"> - -nik@FreeBSD.org"> - -nsayer@FreeBSD.org"> - -nsj@FreeBSD.org"> - -nyan@FreeBSD.org"> - -obrien@FreeBSD.org"> - -olah@FreeBSD.org"> - -opsys@open-systems.net"> - -patrick@FreeBSD.org"> - -paul@FreeBSD.org"> - -pb@fasterix.freenix.org"> - -pds@FreeBSD.org"> - -peter@FreeBSD.org"> - -phantom@FreeBSD.org"> - -phk@FreeBSD.org"> - -pho@FreeBSD.org"> - -piero@strider.inet.it"> - -pjchilds@imforei.apana.org.au"> - -proven@FreeBSD.org"> - -ps@FreeBSD.org"> - -pst@FreeBSD.org"> - -reg@FreeBSD.org"> - -rgrimes@FreeBSD.org"> - -rhuff@cybercom.net"> - -ricardag@ag.com.br"> - -rich@FreeBSD.org"> - -rnordier@FreeBSD.org"> - -roberto@FreeBSD.org"> - -rse@FreeBSD.org"> - -ru@FreeBSD.org"> - -rwatson@FreeBSD.org"> - -sada@FreeBSD.org"> - -scrappy@FreeBSD.org"> - -se@FreeBSD.org"> - -sef@FreeBSD.org"> - -sheldonh@FreeBSD.org"> - -shige@FreeBSD.org"> - -shin@FreeBSD.org"> - -simokawa@FreeBSD.org"> - -smace@FreeBSD.org"> - -smpatel@FreeBSD.org"> - -sos@FreeBSD.org"> - -stark@FreeBSD.org"> - -stb@FreeBSD.org"> - -steve@FreeBSD.org"> - -sumikawa@FreeBSD.org"> - -swallace@FreeBSD.org"> - -tanimura@FreeBSD.org"> - -taoka@FreeBSD.org"> - -tedm@FreeBSD.org"> - -tegge@FreeBSD.org"> - -tg@FreeBSD.org"> - -thepish@FreeBSD.org"> - -tom@FreeBSD.org"> - -torstenb@FreeBSD.org"> - -truckman@FreeBSD.org"> - -ugen@FreeBSD.org"> - -uhclem@FreeBSD.org"> - -ulf@FreeBSD.org"> - -ume@FreeBSD.org"> - -unfurl@FreeBSD.org"> - -vanilla@FreeBSD.org"> - -wes@FreeBSD.org"> - -whiteside@acm.org"> - -wilko@FreeBSD.org"> - -will@FreeBSD.org"> - -wlloyd@mpd.ca"> - -wollman@FreeBSD.org"> - -wosch@FreeBSD.org"> - -wpaul@FreeBSD.org"> - -wsanchez@FreeBSD.org"> - -yokota@FreeBSD.org"> - - - -www@FreeBSD.org"> - diff --git a/ru_RU.KOI8-R/books/handbook/backups/chapter.sgml b/ru_RU.KOI8-R/books/handbook/backups/chapter.sgml deleted file mode 100644 index 19937e1f97..0000000000 --- a/ru_RU.KOI8-R/books/handbook/backups/chapter.sgml +++ /dev/null @@ -1,802 +0,0 @@ - - - -Резервное копирование - - - Описание - - В следующей главе будут описаны методы резервного копирования данных - и используемые для этого программы. Если вы хотите добавить что-то в - этот раздел, пошлите ваш текст на адрес &a.doc;. - - - - Носители на магнитной ленте - - К наиболее часто используемым носителям на магнитной ленте следует - отнести ленты шириной 4мм и 8мм, а также типа QIC, мини-картриджи и - DLT. - - - 4мм (DDS: Digital Data Storage) - - Ленты шириной 4мм заменяют QIC в качестве наиболее - предпочтительного носителя для создания резервных копий. Эта тенденция - значительно усилилась после покупки компанией Conner фирмы Archive, - ведущего производителя накопителей QIC и последующего прекращения - их выпуска. Накопители 4мм малы по размеру и мало шумят, но у них нет - репутации носителя, обладающего надежностью приводов 8мм. Картриджи - более дешевы и меньше по размеру (3 x 2 x 0.5 дюймов, 76 x 51 x 12 мм), - чем 8мм-картриджи. Накопители для лент шириной 4мм, как и 8мм, имеют - сравнительно малый срок службы головок, по причине использования в - обоих случаях технологии спирального сканирования (helical - scan). - - Пропускная способность у таких накопителей начинается с цифры - ~150kB/s, пиковая достигает ~500kB/s. Емкость накопителей начинается с - 1.3 GB и может достигать 2.0 GB. Аппаратное сжатие, имеющееся на - большинстве таких накопителей, дает увеличение емкости примерно вдвое. - Блоки многоприводных ленточных библиотек могут иметь до 6 накопителей - в одном модуле с автоматической сменой ленты. Емкость библиотек может - достигать 240 GB. - - Стандарт DDS-3 в настоящее время поддерживает емкость вплоть до - 12GB (или 24GB сжатой информации). - - В накопителях 4мм, как и в приводах 8мм, используется технология - спирального сканирования. Все плюсы и минусы этой технологии относятся - как к 4мм, так и 8мм приводам. - - Не следует использовать ленты после того, как они были подвергнуты - 2000 проходов, или были использованы для создания 100 полных - копий. - - - - 8мм (Exabyte) - - Ленты шириной 8мм являются самым распространенным типом для - ленточных SCSI-накопителей; они же являются наиболее удачным выбором - при выборе типа носителей для обмена лентами. Наверное, каждый сервер - имеет привод шириной 8мм. Эти приводы удобны, они работают надежно и - тихо. Картриджи дешевы и малы по размеру (4.8 x 3.3 x 0.6 дюймов; - 122 x 84 x 15 мм). Одним минусом лент шириной 8мм является - сравнительно малое время службы головок и лент из-за высокой скорости - движения ленты вдоль головок. - - Скорость передачи данных варьируется от ~250kB/s до ~500kB/s. - Объем хранимых данных начинается с 300МБ и может достигать 7ГБ. - Аппаратное сжатие, имеющееся практически на всех таких приводах, - увеличивает емкость примерно вдвое. Эти приводы существуют как в виде - отдельных модулей, так и в виде многоприводных ленточных библиотек с - 6 приводами и 120 лентами в одном отсеке. Ленты сменяются - автоматически модулем. Емкости библиотек достигают величин, - превышающих 840 ГБ. - - Модель Exabyte Mammoth поддерживает емкость ленты в - 12ГБ (25ГБ со сжатием) и стоит примерно вдвое больше, чем обычный - ленточный накопитель. - - Данные на ленту записываются по технологии спирального - сканирования, головки позиционируются под углом к носителю (примерно в - 6 градусов). Лента оборачивается на 270 градусов вокруг шпульки, - которая держит головки. Во время скольжения ленты вокруг шпульки - последняя вращается. В результате достигается высокая плотность записи - данных с очень близко лежащими дорожками, расположенными под наклоном - по всей ленте. - - - - QIC - - Ленты и накопители формата QIC-150, наверное, являются наиболее - распространенным типом носителей. Приводы лент формата QIC являются - самыми дешевыми "серьезными" накопителями для резервного копирования. - Минусом является стоимость носителей. Ленты формата QIC по сравнению - с лентами шириной 8мм или 4мм являются дорогими, превосходя их по - стоимости хранения одного гигабайта в пять раз. Однако если вам - будут достаточно половины ленты, QIC может оказаться правильным - выбором. QIC является самым распространенным - типом привода. Каждый сайт имеет привод QIC какой-либо емкости. QIC - имеет большое количество плотностей на физически похожих (иногда - даже идентичных) лентах. Приводы QIC работают вовсе не тихо. Эти - накопители громко осуществляют поиск перед тем, как начать запись - данных и достаточно шумны в процессе чтения, записи или поиска. Ленты - QIC имеют размеры (6 x 4 x 0.7 дюймов; 15.2 x 10.2 x 1.7 мм). Мини-картриджи, в которых - также используется лента шириной 1/4", обсуждаются отдельно. - Библиотек лент и роботов для их замены не существует. - - Скорость обмена данными лежит в границах от ~150kB/s до ~500kB/s. - Емкость накопителей варьируется от 40 МБ до 15 ГБ. Аппаратное сжатие - присутствует во многих современных накопителях QIC. Приводы QIC - устанавливаются менее часто; они вытесняются накопителями DAT. - - На ленту данные записываются в виде дорожек. Дорожки располагаются - в длину вдоль всей ленты. Количество дорожек, и, в свою очередь, их - ширина, меняется вместе с емкостью ленты. Большинство, если не все - современные накопители обеспечивают обратную совместимость по крайней - мере для чтения (однако зачастую и для режима записи). Формат QIC - имеет хорошую репутацию в области надежности хранения данных (механика - устроена проще и более надежна, чем в случае накопителей, построенных - по технологии спирального сканирования). - - Ленты не следует больше использовать после создания 5,000 резервных - копий. - - - - * Мини-картриджи - - - - -]]> - - - DLT - - Формат DLT обладает самой высокой скоростью передачи данных среди - всех перечисленных здесь накопителей. Лента шириной 1/2" (12.5мм) - помещена в один картридж с катушкой (4 x 4 x 1 дюймов; 100 x 100 x - 25 мм). Вдоль одной из сторон картриджа расположена сдвигающаяся - крышечка. Механизм накопителя открывает эту крышку, чтобы вытащить - конец ленты. На этом конце имеется овальное отверстие, которое - используется для "захвата" ленты. Принимающая катушка размещена внутри - накопителя. Все другие типы картриджей, перечисленные здесь (за - исключением 9-дорожечных лент), имеют как подающий, так и принимающий - барабаны внутри самого картриджа. - - Скорость передачи данных равна примерно 1.5MB/s, что в три раза - больше скорости передачи данных для накопителей 4мм, 8мм или QIC. - Емкость картриджей варьируется от 10ГБ до 20ГБ для одного накопителя. - Приводы могут компоноваться как многоленточные роботизированные, так - и многоленточные, многоприводные библиотеки лент, вмещающие от 5 до - 900 лент и от 1 до 20 приводов, что дает емкость хранилища от 50ГБ до - 9ТБ. - - Формат DLT Type IV поддерживает емкость до 70ГБ со сжатием. - - Данные на ленту записываются в виде дорожек, параллельных - направлению движения (точно также, как и для лент QIC). Одновременно - записываются две дорожки. Срок жизни головок чтения/записи - сравнительно велик; как только лента перестает двигаться, одновременно - прекращается трение между головками и лентой. - - - - AIT - - AIT - это новый формат фирмы Sony, который позволяет хранить до - 50ГБ (со сжатием) информации на одной ленте. Ленты содержат микросхемы - памяти, на которых размещается каталог содержимого ленты. Этот каталог - может быть быстро считан накопителем для определения расположения - файлов на ленте, вместо того, чтобы тратить несколько минут на поиск, - как это происходит с другими форматами. Такое программное обеспечение, - как SAMS:Alexandria, может управлять сорока или большим количеством - ленточных библиотек AIT, связываясь непосредственно с памятью лент для - вывода их содержимого, определения того, какие файлы были скопированы - на какую ленту, выбора нужной ленты, ее загрузки и восстановления - данных с ленты. - - Библиотеки с такими функциями стоят в районе $20,000, выводя их из - ниши любительского рынка. - - - - Использование новой ленты первый раз - - Если вы попытаетесь прочитать или записать новую, абсолютно чистую - ленту, в первый раз, то вам это не удастся. Выводимые на консоль - сообщения будут выглядеть примерно так: - - -sa0(ncr1:4:0): NOT READY asc:4,1 -sa0(ncr1:4:0): Logical unit is in process of becoming ready - - - На ленте отсутствует идентификационный блок (блок номер 0). Со - времен принятия стандарта QIC-525 все накопители формата QIC записывают - на ленту идентификационный блок (Identifier Block). Здесь имеется два - решения: - - По команде mt fsf 1 ленточный накопитель - записывает идентификационный блок на ленту. - - Воспользуйтесь кнопкой на передней панели для выброса ленты. - - Вставьте ленту повторно и по команде &man.dump.8; сбросьте данные - на ленту. - - Команда &man.dump.8; выдаст DUMP: End of tape - detected, а на консоли будет выведено: HARDWARE - FAILURE info:280 asc:80,96 - - перемотайте ленту такой командой: - mt rewind - - Последующие операции с лентой будут успешными. - - - - - Программы резервного копирования - - Тремя основными программами являются &man.dump.8;, &man.tar.1; и - &man.cpio.1;. - - - Dump и Restore - - &man.dump.8; и &man.restore.8; являются традиционными для Unix - программами резервного копирования. Они работают с приводом как с - набором дисковых блоков, которые расположены ниже понятий файлов, - связей и каталогов, создаваемых файловыми системами. Программа - &man.dump.8; выполняет резервное копирование устройств, целых файловых - систем, но не частей файловой системы и не деревьев каталогов, которые - располагаются более чем в одной файловой системе при помощи - символических ссылок &man.ln.1; или монтирования одной файловой - системы в другой. Утилита &man.dump.8; не записывает на ленту файлы и - каталоги, она записывает блоки данных, из которых строятся файлы и - каталоги. В программе &man.dump.8; имеются некоторые неудобства, - оставшиеся от ее ранних дней в составе Version 6 операционной системы - ATT Unix (около 1975). Параметры, используемые по умолчанию, подходят - для 9-дорожечных лент (6250 bpi), но не для современных носителей с - высокой плотностью записи информации (до 62,182 ftpi). Для - использования емкостей нынешних накопителей на магнитной ленте эти - параметры могут быть заданы в командной строке. - - &man.rdump.8; и &man.rrestore.8; предназначены для резервного - копирования данных по сети на накопитель, подключенный к другому - компьютеру. Обе программы используют в работе &man.rcmd.3; и - &man.ruserok.3; для доступа к накопителю на магнитной ленте на - удаленном компьютере. Поэтому пользователь, выполняющий резервное - копирование, должен иметь доступ к удаленному компьютеру через - rhosts. Аргументы для &man.rdump.8; и - &man.rrestore.8; должны подходить для использования на другом - компьютере. (Например, при выполнении копирования по команде - rdump на компьютере с FreeBSD на накопитель Exabyte, - подключенный к машине Sun по имени komodo, используйте - такую команду: /sbin/rdump 0dsbfu 54000 13000 126 - komodo:/dev/nrsa8 /dev/rda0a 2>&1) Будьте осторожны: - есть проблемы с обеспечением безопасности при разрешении использования - команд rhosts. Внимательно отнеситесь к вашей - ситуации. - - - - Tar - - Утилита &man.tar.1; также восходит корнями к Version 6 системы ATT - Unix (около 1975). &man.tar.1; работает с файловой системой; - &man.tar.1; записывает на ленту файлы и каталоги. &man.tar.1; - поддерживает не полный набор опций, имеющихся в &man.cpio.1;, однако - он не требует необычного перенаправления в командной строке, которое - используется в утилите &man.cpio.1;. - - В большинстве версий &man.tar.1; создание резервных копий по сети - не поддерживается. Версия GNU утилиты &man.tar.1;, которая - используется во FreeBSD, поддерживает удаленные устройства в том же - самом синтаксисе, что и &man.rdump.8;. Чтобы скопировать данные на - накопитель Exabyte, подключенный к машине Sun по имени - komodo, используйте такую команду: - /usr/bin/tar cf komodo:/dev/nrsa8 . 2>&1. В - случае использования версий без поддержки удаленных устройств, вы - можете воспользоваться перенаправлением вывода и командой &man.rsh.1; - для посылки данных на удаленный ленточный накопитель. - - -&prompt.root; tar cf - . | rsh hostname dd of=tape-device obs=20b - - - Если вы беспокоитесь о безопасности создания резервных копий по - сети, то вместо &man.rsh.1; вам нужно использовать &man.ssh.1;. - - - - Cpio - - &man.cpio.1; является оригинальной программой Unix для обмена - файлами на магнитных носителях. В утилите &man.cpio.1; имеются опции - (кроме всего прочего), позволяющие выполнять изменение порядка - следования байтов, поддерживающие различные форматы архивов и - выполняющие перенаправление данных другим программам. Последняя - возможность делает &man.cpio.1; прекрасным выбором для целей установки. - &man.cpio.1; не знает о том, как работать с каталогами, список файлов - должен даваться через stdin. - - &man.cpio.1; не поддерживает создание резервных копий по сети. Вы - можете воспользоваться перенаправлением вывода и программой &man.rsh.1; - для посылки данных на удаленный накопитель. (XXX добавить пример - использования утилиты) - - - - Pax - - &man.pax.1; является ответом IEEE/POSIX на утилиты &man.tar.1; и - &man.cpio.1;. В течении многих лет различные версии программ - &man.tar.1; и &man.cpio.1; получались не совсем совместимыми. Так что - вместо того, чтобы попытаться полностью их стандартизировать, POSIX - создал новую утилиту для работы с архивами. &man.pax.1; пытается - читать и писать различные форматы &man.cpio.1; и &man.tar.1;, и, кроме - того, свои собственные новые форматы. Набор команд этой утилиты больше - напоминает &man.cpio.1;, чем &man.tar.1;. - - - - Amanda - - Amanda - (Advanced Maryland Network Disk Archiver) является целой - клиент/серверной системой резервного копирования, а не отдельной - программой. Сервер Amanda сможет осуществлять резервное копирование - на единственный накопитель любого количества компьютеров, на которых - имеется клиент Amanda и которые могут связываться по сети с сервером - Amanda. Общей проблемой систем с большим количеством больших дисков - является время, требуемое для непосредственной записи данных на ленту, - превышающее лимит времени, выделенный на эту задачу. Amanda решает - эту проблему. Amanda может использовать "промежуточный диск" для - резервного копирования нескольких файловых систем одновременно. Amanda - создает "наборы архивов": группа лент, используемых в некоторый период - времени для создания полных копий всех файловых систем, перечисленных - в конфигурационном файле системы Amanda. "Архивный набор" содержит - также создаваемый каждую ночь инкрементальные (или дифференциальные) - резервные копии всех файловых систем. Восстановление поврежденной - файловой системы требует наличие самой последней полной копии и - инкрементальных резервных копий. - - Конфигурационный файл дает прекрасный механизм управление процессом - резервного копирования и объемом трафика, генерируемого системой - Amanda. Amanda сможет использовать любую из перечисленных выше - программ для записи данных на ленту. Amanda имеется в виде как порта, - так и пакаджа, и по умолчанию она не установлена. - - - - Не делать ничего - - Не делать ничего - это не программа для компьютера, - и в то же время это наиболее широко используемая стратегия резервного - копирования. Здесь нет никаких первоначальных затрат. Здесь нет - расписания, которому нужно следовать. Просто скажите нет. Если что-то - случится с вашими данными, улыбнитесь и забудьте о них! - - Если ваше время и данные практически ничего не стоят, то не - делать ничего является самой подходящей программой для вашего - компьютера. Но будьте осторожны, Unix является весьма полезным - инструментом, и через полгода вы можете обнаружить, что у вас есть - набор файлов, представляющих для вас определенную ценность. - - Ничего не делать является правильным методом - резервного копирования для /usr/obj и других - деревьев каталогов, которые могут быть в точности перегенерированы - вашим компьютером. Примером являются файлы, представляющие страницы - этой книги - они генерируются из входных файлов - SGML. Создание резервных копий файлов - HTML не нужно. Исходные файлы - SGML копируются регулярно. - - - - Какая программа резервного копирования самая лучшая? - - &man.dump.8; Точка. Elizabeth D. Zwicky - протестировала все программы резервного копирования, обсуждаемые здесь. - Беспроигрышным вариантом для сохранения всех ваших данных и - особенностей файловых систем Unix является &man.dump.8;. Элизабет - создала файловые системы, содержащие большое количество необычных - элементов (и некоторых не так уж необычных) и тестировала каждую из - программ, выполняя резервное копирование и последующее восстановление - этих файловых систем. В число необычных элементов входили: файлы с - дырами, файлы с дырами и блоком пустого места, файлы с необычными - символами в их именах, нечитаемые и незаписываемые файлы, устройства, - меняющие свой размер во время резервного копирования, файлы, - создаваемые и удаляемые во время копирования и тому подобное. Она - представила результаты на конференции LISA V в октябре 1991 года. - Посмотрите ссылку на - torture-testing Backup and Archive Programs. - - - - Процедура восстановления при сбое - - - До того, как случится катастрофа - - Вам нужно выполнить всего лишь четыре шага для того, чтобы быть - готовым к любому сбою. - - Во-первых, распечатайте разметку диска для всех ваших дисков - (например, disklabel da0 | lpr), таблицу файловых - систем (/etc/fstab) и все сообщения, выводимые - при загрузке, каждого по два экземпляра. - - Во-вторых, определите, все ли устройства присутствуют на - загрузочной и аварийной дискетах (boot.flp и - fixit.flp). Самым простым способом проверки - является перезагрузка вашей машины с загрузочной дискетой, - вставленной в дисковод и последующая проверка сообщений при загрузке. - Если все имеющиеся у вас устройства здесь будут перечислены и будут - работоспособны, перейдите к третьему шагу. - - В противном случае вам необходимо будет создать две особым - образом сформированные загрузочные дискеты, на которых помещено - ядро, могущее смонтировать все ваши диски и получить доступ к вашему - стримеру. На этих дискетах должны быть: &man.fdisk.8;, - &man.disklabel.8;, &man.newfs.8;, &man.mount.8; и какая-либо - используемая вами программа резервного копирования. Эти программы - должны быть скомпонованы статически. Если вы используете - &man.dump.8;, то на дискете должна присутствовать и программа - &man.restore.8;. - - В-третьих, регулярно создавайте резервные копии на ленте. Любые - изменения, которые вы делали после последнего резервного копирования, - могут быть безвозвратно потеряны. На лентах включайте защиту от - записи. - - В-четвертых, проверяйте работу дискет (либо - boot.flp и fixit.flp, либо - двух дискет, которые вы сделали при выполнении второго шага) и лент - с резервными копиями. Ведите журнал выполняемых действий. Храните - эти записи вместе с загрузочной дискетой, распечатками и лентами. - Вы просто обезумеете при восстановлении данных, если окажется, что - записи могли бы избежать разрушения ваших резервных копий (Каким - образом? Вместо команды tar xvf /dev/rsa0 вы - могли случайно набрать tar cvf /dev/rsa0 и тем - самым перезаписать вашу резервную копию). - - Для дополнительной страховки, каждый раз создавайте загрузочные - дискеты и две резервные копии на ленте. Храните одну из копий в - каком-то удаленном месте и НЕ в том же здании, где находится ваш - офис. Достаточно большое количество компаний во Всемирном Торговом - Центре изучило это на своей шкуре. Это удаленное хранилище должно - быть физически отделено на большое расстояние от ваших компьютеров и - дисковых устройств. - - Пример скрипта для создания загрузочной дискеты: - - - /mnt/sbin/init -gzip -c -best /sbin/fsck > /mnt/sbin/fsck -gzip -c -best /sbin/mount > /mnt/sbin/mount -gzip -c -best /sbin/halt > /mnt/sbin/halt -gzip -c -best /sbin/restore > /mnt/sbin/restore - -gzip -c -best /bin/sh > /mnt/bin/sh -gzip -c -best /bin/sync > /mnt/bin/sync - -cp /root/.profile /mnt/root - -cp -f /dev/MAKEDEV /mnt/dev -chmod 755 /mnt/dev/MAKEDEV - -chmod 500 /mnt/sbin/init -chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt -chmod 555 /mnt/bin/sh /mnt/bin/sync -chmod 6555 /mnt/sbin/restore - -# -# create the devices nodes -# -cd /mnt/dev -./MAKEDEV std -./MAKEDEV da0 -./MAKEDEV da1 -./MAKEDEV da2 -./MAKEDEV sa0 -./MAKEDEV pty0 -cd / - -# -# create minimum filesystem table -# -cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd < - - - - - После сбоя - - Главный вопрос: выжило ли ваше оборудование? Вы регулярно делали - резервные копии, так что нет нужды беспокоиться о программном - обеспечении. - - Если оборудование было повреждено, первым делом замените - неисправные компоненты. - - Если с оборудованием все в порядке, проверьте ваши дискеты. При - использовании самостоятельно созданной загрузочной дискеты, - загрузитесь в однопользовательском режиме (набрав - -s в приглашении boot:). - Пропустите следующий абзац. - - Если вы используете дискеты boot.flp и - fixit.flp, читайте дальше. Вставьте дискету - boot.flp в первый дисковод и загрузите - компьютер. На экран будет выведено оригинальное меню установки. - Выберите пункт Fixit--Repair mode with CDROM or - floppy. После вывода приглашения вставьте - fixit.flp. restore и другие - нужные вам программы находятся в - /mnt2/stand. - - Восстановите по отдельности каждую файловую систему. - - Попробуйте выполнить команду &man.mount.8; (например, - mount /dev/da0a /mnt) по отношению к корневому - разделу вашего первого диска. Если метка диска была испорчена, - то воспользуйтесь командой &man.disklabel.8; для переразбиения на - разделы и разметки диска так, чтобы получившаяся метка совпала с той, - которая вами была распечатана и сохранена. Для повторного создания - файловых систем используйте утилиту &man.newfs.8;. Повторно - смонтируйте корневой раздел дискеты в режиме чтения-записи - (mount -u -o rw /mnt). Воспользуйтесь вашей - программой резервного копирования и резервными копиями на лентах для - восстановления данных для этой файловой системы (например. - restore vrf /dev/sa0). Размонтируйте файловую - систему (например, umount /mnt). Повторите эту - процедуру для каждой файловой системы, которая была запорчена. - - Как только ваша система заработает, сделайте резервную копию на - новые ленты. Что бы ни вызвало сбой или потерю данных, это может - случиться снова. Еще один час, потраченный в этот момент, может - спасти вас от неприятностей в будущем. - - - - * Я не был готов к катастрофе, и что теперь? - - - -]]> - - - - - - Что насчет резервных копий на дискетах? - - - Можно ли использовать дискеты для создания резервных копий моих - данных? - - На самом деле дискеты не подходят для создания резервных копий, - потому что: - - - - Носитель ненадежен, особенно если речь идет о больших сроках - хранения - - - - Создание резервных копий и восстановление данных происходит - очень медленно - - - - Дискеты имеют весьма ограниченную емкость (дни, когда весь - винчестер копировался на десяток или около того дискет, давно - прошли). - - - - Несмотря на все это, если у вас нет другого способа сделать - резервную копию ваших данных, то дискеты все же лучше, чем - ничего. - - Если вы используете дискеты, то проверьте, что они должны быть - хорошего качества. Дискеты, которые валялись по всему офису в течении - нескольких лет, не подойдут. Идеально использовать новые от известного - производителя. - - - - Итак, как же сделать резервную копию данных на дискетах? - - Самым лучшим методом создания резервной копии на дискете является - использование утилиты &man.tar.1; с опцией - (многотомные архивы), которая позволяет размещать архивы на нескольких - дискетах. - - Для копирования всех файлов в текущем каталоге и подкаталогах - выполните следующее (работая как пользователь root): - - -&prompt.root; tar Mcvf /dev/rfd0 * - - - Когда первая дискета окажется полностью заполненной, программа - &man.tar.1; выдаст запрос на следующий том (так как работа утилиты - &man.tar.1; не зависит от носителя, она имеет дело с томами. В этом - смысле это означает дискету) - - -Prepare volume #2 for /dev/rfd0 and hit return: - - - Это сообщение будет повторяться (со все увеличивающимся номером - тома) до тех пор, пока все указанные файлы не будут - заархивированы. - - - - Можно ли резервные копии подвергнуть компрессии? - - К сожалению, &man.tar.1; при создании многотомных архивов не - позволяет использовать опцию . Вы конечно же, - можете скомпрессировать все файлы утилитой &man.gzip.1;, программой - &man.tar.1; скопировать их на дискеты, а затем распаковать файлы - снова утилитой &man.gunzip.1;! - - - - Как восстановить данные из моих резервных копий? - - Для полного восстановления архива воспользуйтесь такой - командой: - - -&prompt.root; tar Mxvf /dev/rfd0 - - - Для восстановления только конкретных файлов вы можете либо начать - с первой дискеты и выдать такую команду: - - -&prompt.root; tar Mxvf /dev/rfd0 filename - - - Программа &man.tar.1; будет выдавать запрос на подачу последующих - дискет до тех пор, пока не найдет требуемый файл. - - Как альтернатива, если вы знаете, на какой дискете расположен файл, - то вы можете просто подать ее и дать ту же самую команду, что и выше. - Заметьте, что если первый файл на дискете является продолжением - предыдущего, то утилита &man.tar.1; выдаст предупреждение о том, что - не может его восстановить, хотя вы этого и не просили делать! - - - - - - diff --git a/ru_RU.KOI8-R/books/handbook/kerneldebug/chapter.sgml b/ru_RU.KOI8-R/books/handbook/kerneldebug/chapter.sgml deleted file mode 100644 index d5515e0e73..0000000000 --- a/ru_RU.KOI8-R/books/handbook/kerneldebug/chapter.sgml +++ /dev/null @@ -1,682 +0,0 @@ - - - - Отладка ядра - - Текст предоставили &a.paul; и &a.joerg; - - - Отладка аварийных образов ядра при помощи - <command>kgdb</command> - - Вот некоторые указания по работе с отладкой ядра с аварийными - образами памяти. При этом предполагается, что у вас достаточно места - на разделе подкачки для аварийного образа памяти. Если у вас есть - несколько разделов подкачки и первый слишком мал для размещения образа - памяти, вы можете настроить ядро на использование другого устройства - для сброса образа памяти (в строке config kernel или - указать его при помощи команды &man.dumpon.8;. Лучше всего - использовать &man.dumpon.8;, задав переменную - dumpdev в файле /etc/rc.conf. - Как правило, вам нужно будет задать одно из устройств подкачки, - перечисленных в файле /etc/fstab. Сброс образов - памяти на устройства, не являющиеся устройствами подкачки, напрмер, - ленты, в данный момент не поддерживаются. Настройте ваше ядро при - помощи команды config -g. Обратитесь к разделу - Настройка ядра за более подробной - информацией о настройке ядра FreeBSD. - - Используйте команду &man.dumpon.8; для указания ядру места, куда - нужно помещать образ памяти (отметьте, что это будут сделано после - настройки соответствующего раздела как раздел подкачки через - &man.swapon.8;). Обычно это делается через - /etc/rc.conf и /etc/rc. - Либо вы можете задать устройство для сброса образа памяти явно через - параметр dump в строке config - конфигурационного файла вашего ядра. Такой способ использовать не - рекомендуется и он должен использоваться, только если вы хотите - получать аварийные образы памяти ядра, которое аварийно завершает свою - работу при загрузке. - - - Далее термин kgdb означает утилиту - gdb, которая запущена в режиме отладки - ядра. Этот режим достигается либо при запуске - gdb с параметром , либо - компоновкой и запуском его под именем kgdb. По - умолчанию этого, однако, не делается и эта идея, в общем-то, не - поддерживается, потому что разработчикам GNU не нравится, когда их - утилиты работают по-другому, будучи вызванными по другому имени. В - будущих релизах такая возможность может исчезнуть. - - - - Если вы используете FreeBSD версии 3 или более раннюю, вы должны - выполнить усечение отладочного ядра командой strip, а не - устанавливать большое отладочное ядро: - - -&prompt.root; cp kernel kernel.debug -&prompt.root; strip -g kernel - - - Этот шаг не так уж и необходим, но рекомендуем. (Во FreeBSD 4 - и более поздних релизах этот шаг выполняется автоматически в конце - процесса построения ядра make.) Когда ядро - усечено, автоматически или при помощи команд выше, вы можете - установить его обычным образом, набрав make - install. - - Заметьте, что в старых версиях FreeBSD (до 3.1, не включая этот - релиз), используется ядра в формате a.out, поэтому их таблицы - символов должны располагаться постоянно в памяти. С большой таблицей - символов в не усеченном отладочном ядре это излишняя трата. Последние - релизы FreeBSD используют ядра в формате ELF, где это не является - проблемой. - - - Если вы тестируете новое ядро, скажем, набирая имя нового ядра в - приглашении загрузчика, но вам нужно загружать и работать с другим - ядром, чтобы снова вернуться к нормальному функционированию, загружайте - его только в однопользовательском режиме при помощи флага - , указываемого при загрузке, а затем выполните такие - шаги: - - -&prompt.root; fsck -p -&prompt.root; mount -a -t ufs # so your file system for /var/crash is writable -&prompt.root; savecore -N /kernel.panicked /var/crash -&prompt.root; exit # ...to multi-user - - - Эта последовательность указывает программе &man.savecore.8; на - использование другого ядра для извлечения символических имен. Иначе - она будет использовать ядро, работающее в данный момент и, скорее - всего, ничего не сделает, потому что аварийный образ памяти и символы - ядра будут отличаться. - - А теперь, после сброса аварийного дампа, перейдите в каталог - /sys/compile/WHATEVER и запустите команду - kgdb. Из программы kgdb сделайте - вот что: - - -symbol-file kernel.debug -exec-file /var/crash/kernel.0 -core-file /var/crash/vmcore.0 - - - и вуаля - вы можете отлаживать аварийный дамп, используя исходные - тексты ядра точно также, как вы это делаете с любой другой - программой. - - Вот журнал команд сеанса работы kgdb, - иллюстрирующий эту процедуру. Длинные строки были разорваны для - улучшения читабельности и для удобства строки были пронумерованы. - Все остальное является трассировкой ошибки, реально возникнувшей во - время работы над драйвером консоли pcvt. - - - 1:Script started on Fri Dec 30 23:15:22 1994 - 2:&prompt.root; cd /sys/compile/URIAH - 3:&prompt.root; kgdb kernel /var/crash/vmcore.1 - 4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel -...done. - 5:IdlePTD 1f3000 - 6:panic: because you said to! - 7:current pcb at 1e3f70 - 8:Reading in symbols for ../../i386/i386/machdep.c...done. - 9:(kgdb) where -10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767) -11:#1 0xf0115159 in panic () -12:#2 0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698) -13:#3 0xf010185e in db_fncall () -14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073) -15:#5 0xf0101711 in db_command_loop () -16:#6 0xf01040a0 in db_trap () -17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723) -18:#8 0xf019d2eb in trap_fatal (...) -19:#9 0xf019ce60 in trap_pfault (...) -20:#10 0xf019cb2f in trap (...) -21:#11 0xf01932a1 in exception:calltrap () -22:#12 0xf0191503 in cnopen (...) -23:#13 0xf0132c34 in spec_open () -24:#14 0xf012d014 in vn_open () -25:#15 0xf012a183 in open () -26:#16 0xf019d4eb in syscall (...) -27:(kgdb) up 10 -28:Reading in symbols for ../../i386/i386/trap.c...done. -29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\ -30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\ -31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\ -32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\ -33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\ -34:ss = -266427884}) (../../i386/i386/trap.c line 283) -35:283 (void) trap_pfault(&frame, FALSE); -36:(kgdb) frame frame->tf_ebp frame->tf_eip -37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done. -38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\ -39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403) -40:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); -41:(kgdb) list -42:398 -43:399 tp->t_state |= TS_CARR_ON; -44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */ -45:401 -46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200) -47:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); -48:404 #else -49:405 return ((*linesw[tp->t_line].l_open)(dev, tp, flag)); -50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */ -51:407 } -52:(kgdb) print tp -53:Reading in symbols for ../../i386/i386/cons.c...done. -54:$1 = (struct tty *) 0x1bae -55:(kgdb) print tp->t_line -56:$2 = 1767990816 -57:(kgdb) up -58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\ -59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126) -60: return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p)); -61:(kgdb) up -62:#2 0xf0132c34 in spec_open () -63:(kgdb) up -64:#3 0xf012d014 in vn_open () -65:(kgdb) up -66:#4 0xf012a183 in open () -67:(kgdb) up -68:#5 0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\ -69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\ -70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \ -71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \ -72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673) -73:673 error = (*callp->sy_call)(p, args, rval); -74:(kgdb) up -75:Initial frame selected; you cannot go up. -76:(kgdb) quit -77:&prompt.root; exit -78:exit -79: -80:Script done on Fri Dec 30 23:18:04 1994 - - - Комментарии к вышеприведенному журналу: - - - - строка 6: - - - Это дамп, взятый при помощи DDB (смотри ниже), поэтому - комментарий к аварийному останову имеет именно вид because - you said to! и трассировка стека глубока; однако - изначальной причиной перехода в DDB была аварийная остановка при - возникновению ошибки страницы памяти. - - - - - строка 20: - - - Это местонахождение функции trap() в - трассировке стека. - - - - - строка 36: - - - Принудительное использование новой границы стека; теперь это - не нужно. Теперь предполагается, что границы стека указывают на - правое расположение, даже в случае аварийного останова. (У меня - нет под рукой новый аварийный дамп <g>, с моим ядром - аварийная ситуация не случалась давно.) Глядя на строку - исходного кода 403, можно сказать, что весьма вероятно, что либо - виноват доступ по указателю tp, либо был выход за - границы массива. - - - - - строка 52: - - - Похоже, что виноват указатель, но он является допустимым - адресом. - - - - - строка 56: - - - Однако, очевидно, что он указывает на мусор, так что мы нашли - нашу ошибку! (Для тех, кто не знаком с этой частью кода: - tp->t_line служит для хранения режима - канала консольного устройства, и это должно быть достаточно - маленькое целое число.) - - - - - - - Отладка аварийного дампа с помощью DDD - - Возможно также и исследование аварийного дампа ядра при помощи - такого графического отладчика, как ddd. Добавьте - флаг к командной строке ddd, - которую вы обычно используете для его вызова. Например; - - -&prompt.root; ddd -k /var/crash/kernel.0 /var/crash/vmcore.0 - - - После этого у вас должно получиться исследование аварийного дампа - при помощи графического интерфейса ddd. - - - - Посмертный анализ дампа - - Что делать, если ядро аварийно завершает работу, хотя этого вы не - хотели и поэтому командой config -g его не - компилировали? Здесь не все еще потеряно. Не паникуйте! - - Конечно, вам нужно включить создание аварийных дампов. Смотрите - выше, что вы должны для этого сделать. - - Перейдите в каталог конфигурации ядра - (/usr/src/sys/arch/conf) - и отредактируйте ваш конфигурационный файл. Раскомментируйте (или - добавьте, если она не существует) такую строку - - -makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols - - - Перестройте ядро. Из-за изменения метки времени в Makefile будут - перестроены некоторые другие объектные файлы, например, - trap.o. К некоторому счастью, добавление опции - не изменит все и вся в генерируемом коде, так что - в конце концов вы получите новое ядро с тем же кодом, что и сбоящее - ядро, за исключением наличия отладочной информации. По крайней мере, - вы можете сравнить старый и новый размеры ядер командой &man.size.1;. - Если они не совпадают, то вам придется отказаться от вашей - затеи. - - Исследуйте дамп так, как это описано выше. Отладочной информации - может не хватать в некоторых местах, как это можно видеть в трассировке - стека примера выше, когда некоторые функции выводятся без номеров строк - и списка аргументов. Если вам нужно больше отладочной информации, - удалите соответствующие объектные файлы и повторите сеанс работы с - kgdb, пока не получите достаточно подробную - информацию. - - Не гарантируется, что все это будет работать, однако в большинстве - случаев все работает прекрасно. - - - - Отладка ядра в режиме реального времени с помощью DDB - - Хотя kgdb является отладчиком не реального - времени с высокоуровневым пользовательским интерфейсом, есть несколько - вещей, которые он сделать не сможет. Самыми важными из них являются - точки останова и пошаговое выполнение кода ядра. - - Если вам нужно выполнять низкоуровневую отладку вашего ядра, то на - этот случай имеется отладчик реального времени, который называется DDB. - Он позволяет устанавливать точки останова, выполнять функции ядра по - шагам, исследовать и изменять переменные ядра и прочее. Однако он не - может использовать исходные тексты ядра и имеет доступ только к - глобальным и статическим символам, а не ко всей отладочной информации, - как kgdb. - - Чтобы отконфигурировать ваше ядро для включения DDB, добавьте - строчку с параметром - - -options DDB - - - в ваш конфигурационный файл, и перестройте ядро. (Обратитесь к разделу - о конфигурации ядра для выяснения - деталей конфигурации ядра FreeBSD. - - - Заметьте, что, если у вас устаревшая версия загрузочных блоков, - то отладочная информация может оказаться не загруженной. Обновите - блоки загрузки; самые новые загружают символы для DDB - автоматически.) - - - После того, как ядро с DDB запущено, есть несколько способов войти - в DDB. Первый, и самый простой, способ заключается в наборе флага - загрузки прямо в приглашении загрузчика. Ядро - будет запущено в режиме отладки и войдет в DDB до выполнения процедуры - распознавания каких бы то ни было устройств. Поэтому вы можете - выполнить отладку даже функций распознавания/присоединения - устройств. - - Второй способ - это особая комбинация клавиш на клавиатуре, как - правило, Ctrl-Alt-ESC. Для системной консоли syscon это может быть - переопределено; некоторые из поставляемых раскладок это выполняют, так - что присмотритесь. Для последовательных консолей имеется параметр, - позволяющий использовать последовательность BREAK на канале консоли для - входа в DDB (options BREAK_TO_DEBUGGER в - конфигурационном файле ядра). По умолчанию этого не делается, так как - существует множество паршивых последовательных адаптеров, которые - генерируют последовательность BREAK, к примеру, при вытягивании - кабеля. - - Третий способ заключается во входе в DDB при возникновении - любой аварийной ситуации, если ядро его использует. По этой причине - не очень умно конфигурировать ядро с DDB для машины, которая работает - без присмотра. - - Команды DDB примерно повторяют некоторые команды - gdb. Первым делом вам, наверное, нужно задать точку - останова: - - -b function-name -b address - - - Значения по умолчанию воспринимаются в шестнадцатиричном виде, но - чтобы отличать их от имен символов; шестнадцатиричные числа, - начинающиеся с букв a-f, должны предваряться - символами 0x (это опционально для других чисел). - Разрешены простые выражения, например: - function-name + 0x103. - - Чтобы продолжить работу прерванного ядра, просто наберите: - - c - - Чтобы получить трассировку стека, задайте: - - trace - - - Заметьте, что при входе в DDB по специальной комбинации, ядро - в данный момент обслуживает прерывание, так что трассировка стека - может не дать много информации. - - - Если вы хотите убрать точку останова, введите - - -del -del address-expression - - - В первом варианте команда будет исполнена сразу же по достижении - точки останова, а текущая точка останова будет удалена. Во второй - форме можно удалить любую точку останова, однако вам нужно будет - указать ее точный адрес; его можно получить из: - - show b - - Чтобы выполнить один шаг ядра, попробуйте: - - s - - При этом будет осуществляться пошаговое выполнение функций, однако - вы можете трассировать их с помощью DDB, пока не будет достигнуто - соответствие возвращаемому значению: - - n - - - Это отличается от команды next отладчика - gdb; это похоже на команду gdb - finish. - - - Чтобы выводить значения в памяти, используйте, (к примеру): - - -x/wx 0xf0133fe0,40 -x/hd db_symtab_space -x/bc termbuf,10 -x/s stringbuf - - - для доступа к данным типа слово/полуслово/байт и вывода в - шестнадцатиричном/десятичном/символьном виде. Число после запятой - означает счетчик объектов. Чтобы вывести следующие 0x10 объектов, - просто укажите: - - x ,10 - - Подобным же образом используйте - - x/ia foofunc,10 - - для дизассемблирования и вывода первых 0x10 инструкций функции - foofunc вместе с их адресом относительно - начала foofunc. - - Чтобы изменить значения в памяти, используйте команду write: - - -w/b termbuf 0xa 0xb 0 -w/w 0xf0010030 0 0 - - - Модификатор команды - (b/h/w) - указывает на размер записываемых данных, первое следующее за ним - выражение является адресом для записи, а оставшаяся часть - интерпретируется как данные для записи в доступные области - памяти. - - Если вам нужно узнать текущее содержимое регистров, - используйте: - - show reg - - Альтернативно вы можете вывести содержимое одного регистра по - команде, скажем, - - p $eax - - и изменить его по: - - set $eax new-value - - Если вам нужно вызвать некоторую функцию ядра из DDB, просто - укажите: - - call func(arg1, arg2, ...) - - Будет выведено возвращаемое значение. - - Для вывода суммарной статистики по всем работающим процессам в - стиле команды &man.ps.1; воспользуйтесь такой командой: - - ps - - Теперь вы узнали, почему ядро работает с ошибками и хотите - выполнить перезагрузку. Запомните, что в зависимости от влияния - предыдущих ошибок, не все части ядра могут работать так, как ожидается. - Выполните одно из следующих действий для закрытия и перезагрузки вашей - системы: - - panic - - Это приведет к созданию дампа ядра и перезагрузке, так что позже - вы можете проанализировать дамп на более высоком уровне при помощи - kgdb. Как правило, эта команда должна следовать за другой командой - continue. - - call boot(0) - - Это может оказаться хорошим способом для корректного закрытия - работающей системы, sync() для всех дисков и - напоследок перезагрузка. Пока интерфейсы диска и файловой системы - в ядре не повреждены, это может быть самым правильным способом закрытия - системы. - - call cpu_reset() - - самый последнее средство при аварии и практически то же самое, что - нажатие Большой Красной Кнопки. - - Если вам нужен краткий справочник по командам, просто - наберите: - - help - - Однако настоятельно рекомендуем отпечатать копию страницы - справочника по &man.ddb.4; при подготовке к сеансу отладки. Помните, - что трудно читать онлайновое руководство при пошаговом выполнении - ядра. - - - - Отладка ядра в режиме реального времени при помощи удаленного - GDB - - Эта возможность поддерживается во FreeBSD начиная с версии 2.2, - и она на самом деле очень удобна. - - В GDB уже давно имеется поддержка удаленной - отладки. Это делается при помощи весьма простого протокола - по последовательному каналу. В отличие от других методов, описанных - выше, для этого вам требуется наличие двух машин. Одна из них является - хостом, предоставляющим ресурсы для отладки, включая все исходные - тексты и копию ядра со всеми символами в нем, а другая является целевой - машиной, на которой запущена та же копия того же ядра (но без - отладочной информации). - - Вы должны настроить исследуемое ядро при помощи команды - config -g, включить в - конфигурацию и откомпилировать его обычным образом. Это даст большой - объем получаемого бинарного файла из-за отладочной информации. - Скопируйте это ядро на целевую машину, усеките отладочную информацию - командой strip -x и загрузите это ядро с - использованием параметра загрузки . Подключите - последовательный канал целевой машины, имеющий установленные флаги - "flags 080" на соответствующем устройстве sio к любому - последовательному каналу отладочного хоста. А теперь на отладочной - машине перейдите в каталог компиляции целевого ядра и запустите - gdb: - - -&prompt.user; gdb -k kernel -GDB is free software and you are welcome to distribute copies of it - under certain conditions; type "show copying" to see the conditions. -There is absolutely no warranty for GDB; type "show warranty" for details. -GDB 4.16 (i386-unknown-freebsd), -Copyright 1996 Free Software Foundation, Inc... -(kgdb) - - - Проинициализируйте сеанс удаленной отладки (предполагается, что - используется первый последовательный порт) такой командой: - - -(kgdb) target remote /dev/cuaa0 - - - Теперь на целевом хосте (тот, который перешел в DDB даже до - начала процесса обнаружения устройств) наберите: - - -Debugger("Boot flags requested debugger") -Stopped at Debugger+0x35: movb $0, edata+0x51bc -db> gdb - - - DDB ответит следующим: - - Next trap will enter GDB remote protocol mode - - Каждый раз, когда вы будете набирать gdb, режим - будет меняться между удаленным GDB и локальным DDB. Чтобы немедленно - вызвать следующее прерывание, просто наберите s - (step). Ваш хостирующий GDB получит управление над целевым - ядром: - - -Remote debugging using /dev/cuaa0 -Debugger (msg=0xf01b0383 "Boot flags requested debugger") - at ../../i386/i386/db_interface.c:257 -(kgdb) - - - Вы можете работать в этом сеансе точно также, как и в любом другом - сеансе GDB, включая полный доступ к исходным текстам, запуск его в - режиме gud-mode внутри окна Emacs (что дает вам автоматический вывод - исходного кода в другом окне Emacs) и тому подобное. - - Удаленный GDB также может использоваться для отладки модулей LKM. - Сначала откомпилируйте LKM с отладочной информацией: - - -&prompt.root; cd /usr/src/lkm/linux -&prompt.root; make clean; make COPTS=-g - - - Затем установите эту версию модуля на целевой машине, загрузите его - и воспользуйтесь командой modstat для определения - того, куда он был загружен: - - -&prompt.root; linux -&prompt.root; modstat -Type Id Off Loadaddr Size Info Rev Module Name -EXEC 0 4 f5109000 001c f510f010 1 linux_mod - - - Возьмите адрес загрузки модуля и добавьте к нему 0x20 (для размера - заголовка a.out). Получится адрес, куда был перемещен код модуля. - Воспользуйтесь командой add-symbol-file в GDB для - указания отладчику на модуль: - - -(kgdb) add-symbol-file /usr/src/lkm/linux/linux_mod.o 0xf5109020 -add symbol table from file "/usr/src/lkm/linux/linux_mod.o" at -text_addr = 0xf5109020? (y or n) y -(kgdb) - - - Теперь вы имеете доступ ко всем символам в LKM. - - - - Отладка драйвера консоли - - Так как для работы DDB вам требуется драйвер консоли, то в случае - неисправностей самого драйвера консоли все становится гораздо сложнее. - Вы можете вспомнить об использовании последовательной консоли (либо с - исправленными загрузочными блоками, либо при указании флага - в приглашении Boot:) и подключить - обычный терминал к первому последовательному порту. DDB работает с - любым отконфигурированным драйвером консоли, в том числе, конечно же, - и с последовательной консолью. - - - - diff --git a/ru_RU.KOI8-R/books/handbook/kernelopts/chapter.sgml b/ru_RU.KOI8-R/books/handbook/kernelopts/chapter.sgml deleted file mode 100644 index 8f2ea2e584..0000000000 --- a/ru_RU.KOI8-R/books/handbook/kernelopts/chapter.sgml +++ /dev/null @@ -1,177 +0,0 @@ - - - - Добавление новых параметров конфигурации ядра - - Предоставил &a.joerg; - - - Перед тем, как читать этот раздел, вы должны усвоить материал - раздела о конфигурации ядра. - - - - Что же такое <emphasis>параметр ядра</emphasis>, в конце - концов? - - Использование параметров ядра в основном описано в разделе о конфигурации ядра. Там же - имеется описание устаревших и параметров в новом - стиле. Конечной целью является постепенный перевод всех - поддерживаемых параметров ядра к новому стилю, так чтобы для тех, кто - корректно выполняют команду make depend в каталоге - компиляции ядра после запуска &man.config.8;, процесс построения - автоматически принимал модифицированные параметры и - перекомпилировал только те файлы, которые необходимы. Удаление старого - каталога компиляции при каждом перезапуске &man.config.8;, как это - еще происходит сейчас, затем может быть убрано. - - В своей основе параметр ядра является не более чем определение - макроса препроцессора C для процесса компиляции ядра. Чтобы сделать - построение полностью настраиваемым через опции процессом, - соответствующая часть исходных текстов ядра (или файла - .h ядра) должна быть написана с упором на - концепцию параметров, то есть чтобы значения, используемые по - умолчанию, могли быть переопределены параметрами конфигурации. Это - обычно делается примерно так: - - -#ifndef THIS_OPTION -#define THIS_OPTION (некоторое значение по умолчанию) -#endif /* THIS_OPTION */ - - - Этим способом администратор, задающий другое значение для параметра - в своем конфигурационном файле, избегает использования значения по - умолчанию и заменяет его новым значением. Более того, новое значение - будет подставлено в исходный код во время работы препроцессора, так что - это должно быть правильное выражение языка C в контексте использования - значения по умолчанию. - - Также возможно создание параметров, которые не принимают - определенного значения, а просто включают или выключают некоторую часть - кода, обрамляя его в - - -#ifdef THAT_OPTION - -[здесь ваш код] - -#endif - - - Простое упоминание THAT_OPTION в - конфигурационном файле (со значением или без него) приведет к включению - соответствующего кода. - - Те, кто знаком с языком C, могут сказать, что все может считаться - как config option, там где есть по крайней мере одна - строчка #ifdef... Однако вряд ли многие будут - писать - - -options notyet,notdef - - - в своих конфигурационных файлах и потом удивляться, почему - компиляция ядра не проходит. :-) - - Более точно, использование уникальных имен для параметров делает - очень трудным отслеживание их использования в дереве исходных текстов - ядра. В использовании схемы параметров в новом - стиле имеется рациональное зерно, когда каждый параметр - помещается в отдельный файл .h в каталоге - компиляции ядра, который по соглашению называется - opt_foo.h. Таким - образом, могут быть применены обычные зависимости в Makefile, и утилита - make может определить, что нужно перекомпилировать - при изменении определенного параметра. - - Параметры при использовании механизма в старом стиле имеют одно - преимущество для локальных изменений или для экспериментальных - параметров, которые имеют короткий срок жизни: так как весьма легко - добавить новую строку #ifdef к исходному коду ядра, - то это уже превращается в параметр конфигурации ядра. В таком случае - администратор, использующий параметры таким образом, несет - ответственность за знание влияния этого параметра (и может быть, за - принудительную перекомпиляцию вручную частей ядра). Как только перевод - всех поддерживаемых опций будет сделан, программа &man.config.8; будет - выдавать предупреждение о не поддерживаемой опции, появившейся в - конфигурационном файле, однако она будет включать ее в файл Makefile - ядра. - - - - И что я должен для этого сделать? - - Во-первых, отредактируйте файл - sys/conf/options (или - sys/<arch>/conf/options.<arch>, - например sys/i386/conf/options.i386), и выберите - файл opt_foo.h, - в котором лучше всего поместить вашу новую опцию. - - Если имеется что-то, уже похожее на предназначение новой опции, - выберите это. Например, опции, изменяющие общее поведение подсистемы - SCSI, могут быть помещены в - opt_scsi.h. По умолчанию простое упоминание опции - в соответствующем файле опций, скажем, FOO, приводит - к тому, что ее значение помещается в соответствующий файл - opt_foo.h. Это может быть переопределено в - правой части правила указанием другого имени файла. - - Если файла - opt_foo.h для - предполагаемой новой опции еще нет, придумайте новое имя. Сделайте его - значимым и прокомментируйте новый раздел в файле - options[.<arch>]. - Утилита &man.config.8; автоматически воспримет изменения и создаст - этот файл при следующем своем запуске. Большинство опций должно - оказаться в заголовочном файле.. - - Размещение слишком большого количества опций в одном файле - opt_foo.h приведет к - перестроению слишком большого количества файлов ядра при изменении - одной из опций в конфигурационном файле. - - Наконец, определите, какие файлы ядра зависят от новой опции. Если - только вы не только что придумали вашу опцию и она еще нигде не - упоминается, то команда - -&prompt.user; find /usr/src/sys -type f | xargs fgrep NEW_OPTION - - вам поможет ее найти. Сделайте это и отредактируйте все эти файлы, а - также добавьте #include "opt_foo.h" - вверху до всех строк - #include <xxx.h>. Эта последовательность - очень важна, так как опции могут переопределять значения по умолчанию - из обычных включаемых файлов, если эти значения по умолчанию даются в - форме #ifndef NEW_OPTION #define NEW_OPTION (что-то) - #endif в обычном заголовке. - - Добавление опции, которая переопределяет что-то в системном - заголовочном файле (то есть файле, находящемся в каталоге - /usr/include/sys/), практически всегда ошибочно. - opt_foo.h не может быть - включен в те файлы, потому что это изменит заголовки более серьезно, - но если он не включен, то в местах его включения может получиться - рассогласованность значений для этой опции. Да, такие прецеденты имеют - место и сейчас, но это их не оправдывает. - - - - \ No newline at end of file diff --git a/ru_RU.KOI8-R/books/handbook/newsgroups.ent b/ru_RU.KOI8-R/books/handbook/newsgroups.ent deleted file mode 100644 index 7c59dbd188..0000000000 --- a/ru_RU.KOI8-R/books/handbook/newsgroups.ent +++ /dev/null @@ -1,11 +0,0 @@ - - -comp.unix.bsd.freebsd.misc"> diff --git a/ru_RU.KOI8-R/books/handbook/policies/chapter.sgml b/ru_RU.KOI8-R/books/handbook/policies/chapter.sgml deleted file mode 100644 index 5dd2e86b3e..0000000000 --- a/ru_RU.KOI8-R/books/handbook/policies/chapter.sgml +++ /dev/null @@ -1,431 +0,0 @@ - - - - Рекомендации и требования к исходному коду - - Текст предоставил &a.phk;. - - В этой главе описываются различные рекомендации и требования, которые - должны соблюдаться в дереве исходных текстов FreeBSD. - - - <makevar>MAINTAINER</makevar> в make-файлах - - Июнь 1996. - - Если некоторая часть дистрибутива FreeBSD поддерживается некоторым - человеком или группой людей, они могут сообщить об этом миру, добавив - строчку - - -MAINTAINER= email-addresses - - в файл Makefile, соответствующий этой части - исходного кода. - - Смысл этого в следующем: - - Сопровождающий владеет кодом и отвечает за него. Это означает, что - он несет ответственность за исправление ошибок и закрывает сообщения о - проблемах, имеющих отношение к этой части кода, а в случае программного - обеспечения, взятого из третьих источников, соответственно отвечает за - отслеживание новых версий. - - Изменения в каталогах, для которых известен сопровождающий, прежде - чем они будут внесены, должны быть посланы ему на рассмотрение. Только - если сопровождающий не отвечает в течение достаточно большого периода - времени на несколько посланий по электронной почте, разрешается внести - изменения без участия сопровождающего. Однако рекомендуется, чтобы вы - попытались передать изменения на рассмотрение кому-либо еще, если это - вообще возможно. - - Конечно же, нельзя назначать человека или группу лиц - сопровождающими, если они не согласны выполнять эту работу. С другой - стороны, необязательно это должен быть конкретный коммиттер, это может - быть и группа людей. - - - - Программное обеспечение третьих сторон - - Текст предоставили &a.phk; и &a.obrien;. - - Июнь 1996. - - Некоторые части дистрибутива FreeBSD состоят из программного - обечпечения, которое сопровождается вне проекта FreeBSD. По - историческим причинам мы называем такое программное обеспечение - контрибуцированным (contributed), или третьих - сторон. Примерами этого могут служить утилиты perl, gcc и - patch. - - За последние несколько лет для работы с таким программным - обеспечением использовались различные методы, и все они имели свои - достоинства и недостатки. Абсолютно подходящего метода так и не - нашлось. - - По этой причине после некоторых дебатов был выбран и признан - официальным один из этих методов, который необходимо - применять в будущем при импортировании такого рода программного - обеспечения. Более того, настоятельно рекомендуется с течением времени - перевести существующее программное обеспечение третьих сторон на этот - метод, так как он имеет значительные преимущества перед старым методом, - включая возможность легкого получения diff-файлов относительно - официальных версий исходных текстов кем угодно (даже - не имеющим доступа к cvs). Это делает данный метод гораздо проще - в использовании при необходимости выдачи изменений изначальным - разработчикам такого программного обеспечения. - - В конце концов, однако, это касается тех, кто делает реальную - работу. Если использование этой модели в конкретном случае не подходит - для пакета, с которым работает человек, могут быть сделаны и - исключения только с согласия основной команды разработчиков и при общем - одобрении других разработчиков. Возможность сопровождения пакета в - будущем будет являться ключевым моментом при принятии решений. - - - Из-за досадных ограничений в дизайне формата файлов RCS и - использовании веток поставщика в CVS, мелкие, тривиальные и/или - косметические изменения сильно не рекомендуется - в файлах, которые все еще отслеживаются в ветке поставщика. Это - касается и исправления орфографических ошибок как - относящихся к категории косметических и избегаемых - для файлов с версиями 1.1.x.x. Рост объема хранилища, вызванный - изменением в один символ, может оказаться весьма большим. - - - В качестве примера того, как работает эта модель, будем - использовать встраиваемый язык программирования - TCL: - - Каталог src/contrib/tcl содержит исходные - тексты пакета в том виде, в котором они распространяются его - создателями. Части, которые полностью не применимы во FreeBSD, могут - быть удалены. В случае Tcl подкаталоги mac, - win и compat были удалены - перед операцией импортирования - - Каталог src/lib/libtcl содержит только файл - Makefile "в стиле bmake", который использует - стандартные правила bsd.lib.mk make-файла для - построения библиотеки и установки документации. - - В каталоге src/usr.bin/tclsh размещаются - make-файлы в стиле bmake, которые отвечают за построение и установку - программы tclsh и связанных с ней справочных - страниц при помощи стандартных правил из - bsd.prog.mk. - - Каталог src/tools/tools/tcl_bmake содержит - несколько shell-скриптов, которые могут помочь при обновлении - программного обеспечения tcl. Они не являются частью строящегося и - исталлируемого программного обеспечения. - - Здесь важно то, что каталог src/contrib/tcl - создавался в соответствии с правилами: Предполагается, что он содержит - исходнве тексты в том виде, в котором они распространяются (в - соответствующей ветви поставщика CVS и без расширения ключевых слов - RCS) с максимально малым количеством изменений, специфичных для - FreeBSD. Утилита 'easy-import' на машине freefall поможет в - импортировании, но если есть сомнения по поводу выполнения этой - операции, то обязательно спросите совета и не действуйте слепо в - расчете на то, что все сработает. CVS не прощает ошибок - импортирования и для ликвидации последствий больших ошибок требуются - значительные усилия. - - Из-за ранее отмеченных ограничений дизайна веток поставщиков в CVS - требуется, чтобы официальные патчи от разработчика - были сначала применены к распространяемым исходным текстам, а затем - результат снова импортирован в ветку поставщика. Официальные патчи - никогда не должны применяться к версии, извлеченной из хранилища - FreeBSD, а затем "коммититься", так как это привдет к рассинхронизации - дерева производителя и усложнит импортирование будущих версий, так как - возникнут конфликты. - - Так как многие пакеты содержат файлы, имеющие значение при - обеспечении совместимости с другими, отличными от FreeBSD архитектурами - и окружениями, то разрешается удалять части дистрибутивного дерева, - не представляющие интереса для FreeBSD в целях уменьшения занимаемого - дискового пространства. Файлы, содержащие замечания о юридических - правах и информацию о релизе, касающуюся остальных файлов, удаляться - не должны. - - Если это видится легким, то файлы Makefile в - стиле bmake могут быть сгенерированы из - дистрибутивного дерева автоматически некоторой утилитой, чем-то, что - позволит еще проще обновляться до новой версии. Если это будет - сделано, то обязательно поместите эту утилиту (если необходимо) в - каталог src/tools вместе с самим портом, чтобы - она была доступна будущим сопровождающим лицам. - - В каталог src/contrib/tcl должен быть добавлен - файл FREEBSD-upgrade, в котором нужно перечислить - такие вещи: - - - - Какие файлы были оставлены - - - - Где был взят оригинальный дистрибутив и/или на каком основном - официальном сайте он находится. - - - - Куда посылать патчи для разработчиков пакета - - - - Возможно, обзор сделанных изменений, специфичных для - FreeBSD. - - - - Однако, пожалуйста, не импортируйте - FREEBSD-upgrade вместе с исходными текстами - этого программного обеспечения. Вместо этого вы должны выполнить - команды cvs add FREEBSD-upgrade ; cvs ci после - первоначального импортирования. Ниже дается пример описания из - каталога src/contrib/cpio: - - -This directory contains virgin sources of the original distribution files -on a "vendor" branch. Do not, under any circumstances, attempt to upgrade -the files in this directory via patches and a cvs commit. New versions or -official-patch versions must be imported. Please remember to import with -"-ko" to prevent CVS from corrupting any vendor RCS Ids. - -For the import of GNU cpio 2.4.2, the following files were removed: - - INSTALL cpio.info mkdir.c - Makefile.in cpio.texi mkinstalldirs - -To upgrade to a newer version of cpio, when it is available: - 1. Unpack the new version into an empty directory. - [Do not make ANY changes to the files.] - - 2. Remove the files listed above and any others that don't apply to - FreeBSD. - - 3. Use the command: - cvs import -ko -m 'Virgin import of GNU cpio v<version>' \ - src/contrib/cpio GNU cpio_<version> - - For example, to do the import of version 2.4.2, I typed: - cvs import -ko -m 'Virgin import of GNU v2.4.2' \ - src/contrib/cpio GNU cpio_2_4_2 - - 4. Follow the instructions printed out in step 3 to resolve any - conflicts between local FreeBSD changes and the newer version. - -Do not, under any circumstances, deviate from this procedure. - -To make local changes to cpio, simply patch and commit to the main -branch (aka HEAD). Never make local changes on the GNU branch. - -All local changes should be submitted to "cpio@gnu.ai.mit.edu" for -inclusion in the next vendor release. - -obrien@FreeBSD.org - 30 March 1997 - - - - - Нежелательные файлы - - Иногда может быть необходимо включить некоторый нежелатеьный для - нас файл в дерево исходных текстов FreeBSD. Например, если устройство - требует загрузки в него некоторого маленького двоичного кода перед тем, - как устройство заработает, и мы не имеем исходных текстов этого кода, - то говорится, что двоичный файл является нежелательным. Для включения - нежелательных файлов в дерево исходных текстов FreeBSD имеются - следующие соглашения. - - - - Любой файл, интерпретируемый или выполняемый системным(и) CPU, - не в форме исходного кода, является нежелательным. - - - - Любой файл с лицензией, ограничивающей более, чем BSD или GNU, - является нежелательным. - - - - Файл, содержащий загружаемые двоичные данные, используемые - аппаратным обеспечением, не являются нежелательными, если только - к нему не применимы условия (1) или (2). Он должен быть сохранен в - нейтральном к архитектуре формате ASCII (рекомендуется применить - утилиты file2c или uuencode). - - - - Люой нежелательный файл требует особое согласие со стороны - основной команды разработчиков до - того, как он будет добавлен в хранилище CVS. - - - - Нежелательные файлы помещаются в каталог - src/contrib или - src/sys/contrib. - - - - Части одного модуля должны храниться вместе. Нет необходимости - разбивать их, если только нет совместного использования с кодом, - не являющимся нежелательным. - - - - Объектные файлы именуются - arch/filename.o.uu>. - - - - Файлы ядра; - - - - Должны всегда упоминаться в - conf/files.* (для упрощения - построения). - - - - Должны всегда присутствовать в LINT, - но основная команда - разработчиков решает в каждом конкретном случае, должны - ли они быть раскомментированы или нет. Конечно, позже основная команда разработчиков - может изменить свое решение. - - - - Вопрос о вхождении в состав релиза решается инженером, ответственным за - релиз. - - - - - - Файлы уровня пользователя; - - - - Основная команда - разработчиков решает, должен ли код стать частью - выполнения команды make world. - - - - Релиз-инженер решает, - войдут ли они в релиз. - - - - - - - - Динамические библиотеки - - Текст предоставили &a.asami;, &a.peter;, и &a.obrien; 9 - декабря 1996. - - Если вы добавляете поддержку динамических библиотек к порту или - другой части программного обеспечения, которая этой возможностью не - обладает, то номера версий должны назначаться по нижеследующим - правилам. Как правило, получающиеся номера не имеют ничего общего с - номером релиза программного обеспечения. - - При построении динамической библиотеки используются три - принципа: - - - - Начинаем с 1.0 - - - - Если есть изменение, которое имеет обратную совместимость, - увеличиваем младший номер версии (заметьте, что системы ELF его - игнорируют) - - - - Если есть изменение, не соблюдающее совместимость, увеличиваем - старший номер версии - - - - К примеру, добавление функций и исправление ошибок приводит к - увеличению младшего номера версии, а удаление функций, изменение - синтаксиса вызова функции и тому подобные изменения приводят к - изменению старшего номера версии. - - Следуйте схеме нумерации версий в форме старший.младший - (x.y). Наш - динамический загрузчик формата a.out не умеет нормально работать с - номерами версий в форме - x.y.z. - Любой номер версии после y (то есть третье - число) полностью игнорируется при сравнении номеров версий динамических - библиотек для определения того, с какой библиотекой осуществлять - компоновку. Если есть две динамические библиотеки, отличающиеся только - микро-номером версии, то ld.so будет - осуществлять компоновку с наибольшим номером. Другими словами: если - вы компонуете с libfoo.so.3.3.3, то компоновщик - запишет в заголовках только 3.3 и будет выполнять - компоновку с любой библиотекой, начинающейся с - libfoo.so.3.(все, что >= - 3).(наибольшее из - доступного). - - - ld.so всегда будет использовать наибольшую - младшую версию. Иными словами: он будет предпочитать - использовать libc.so.2.2, а не - libc.so.2.0, даже если программа изначально была - скомпонована с libc.so.2.0. - - - Вдобавок наш динамический компоновщик ELF совсем не работает с - младшими версиями. Однако все же нужно указывать старший и младший - номер версии, а наши файлы Makefile "сделают все - как нужно" в зависимости от типа системы. - - Для библиотек не в составе портов, имеется наше соглашение на - изменение номера версии динамической библиотеки только один раз между - релизами. Кроме того, есть договоренность на изменение старшего - номера динамической библиотеки только один раз между главными релизами - ОС. А именно: X.0 на (X+1).0. Когда вы делаете изменение в системной - библиотеке, которое требует увеличения номера версии, посмотрите - журналы коммитов изменений в файле Makefile. - Коммиттер отвечает за то, что первое такое изменение с момента релиза - приведет к обновлению номера версии динамической библиотеки в файле - Makefile, а при других последующих изменениях - этого бы не делалось. - - - - \ No newline at end of file diff --git a/ru_RU.KOI8-R/books/handbook/staff/chapter.sgml b/ru_RU.KOI8-R/books/handbook/staff/chapter.sgml deleted file mode 100644 index 3c16baaf44..0000000000 --- a/ru_RU.KOI8-R/books/handbook/staff/chapter.sgml +++ /dev/null @@ -1,1285 +0,0 @@ - - - - - - Коллектив Проекта FreeBSD - - Проект FreeBSD контролируется и действует при участии следующих - групп людей: - - - Core Группа FreeBSD - - Core Группа FreeBSD представляет собой Совет - Директоров, ответственных за решение вопросов связанных - общими целями проекта и его руководством и руководство отдельных направлений развития проекта - FreeBSD. - - (в алфавитном порядке, отсортировано по фамилии): - - - - &a.asami; - - - - &a.dg; - - - - &a.jkh; - - - - &a.grog; - - - - &a.imp; - - - - &a.dfr; - - - - &a.msmith; - - - - &a.rwatson; - - - - &a.peter; - - - - - - - - Разработчики FreeBSD - - Это люди, которые имеют права доступа к Главному Репозиторию - FreeBSD и занимаются основной работой над исходными текстами FreeBSD. - Члены Core Группы также являются разработчиками. - - - - &a.akiyama; - - - - &a.jmas; - - - - &a.will; - - - - &a.ugen; - - - - &a.toshi; - - - - &a.babkin; - - - - &a.dbaker; - - - - &a.jhb; - - - - &a.mbarkah; - - - - &a.dougb; - - - - &a.stb; - - - - &a.pb; - - - - &a.abial; - - - - &a.jb; - - - - &a.nbm; - - - - &a.jmb; - - - - &a.torstenb; - - - - &a.wilko; - - - - &a.jake; - - - - &a.dburr; - - - - &a.adrian; - - - - &a.charnier; - - - - &a.jon; - - - - &a.luoqi; - - - - &a.ache; - - - - &a.ejc; - - - - &a.kjc; - - - - &a.cjh; - - - - &a.archie; - - - - &a.chris; - - - - &a.alc; - - - - &a.cracauer; - - - - &a.dec; - - - - &a.adam; - - - - &a.bsd; - - - - &a.jwd; - - - - &a.dillon; - - - - &a.mdodd; - - - - &a.gad; - - - - &a.dufault; - - - - &a.uhclem; - - - - &a.tegge; - - - - &a.deischen; - - - - &a.eivind; - - - - &a.julian; - - - - &a.rse; - - - - &a.ru; - - - - &a.se; - - - - &a.bde; - - - - &a.jasone; - - - - &a.sef; - - - - &a.jedgar; - - - - &a.green; - - - - &a.fenner; - - - - &a.lioux; - - - - &a.jfieber; - - - - &a.jfitz; - - - - &a.scrappy; - - - - &a.lars; - - - - &a.dirk; - - - - &a.shige; - - - - &a.billf; - - - - &a.gallatin; - - - - &a.patrick; - - - - &a.tg; - - - - &a.gibbs; - - - - &a.brandon; - - - - &a.gioria; - - - - &a.graichen; - - - - &a.cg; - - - - &a.rgrimes; - - - - &a.jmg; - - - - &a.hanai; - - - - &a.roger; - - - - &a.mharo; - - - - &a.dannyboy; - - - - &a.thepish; - - - - &a.jhay; - - - - &a.sheldonh; - - - - &a.helbig; - - - - &a.ghelmer; - - - - &a.erich; - - - - &a.nhibma; - - - - &a.flathill; - - - - &a.pho; - - - - &a.horikawa; - - - - &a.hosokawa; - - - - &a.jeh; - - - - &a.hsu; - - - - &a.foxfair; - - - - &a.tom; - - - - &a.mph; - - - - &a.shin; - - - - &a.itojun; - - - - &a.iwasaki; - - - - &a.mjacob; - - - - &a.keith; - - - - &a.gj; - - - - &a.nsj; - - - - &a.trevor; - - - - &a.phk; - - - - &a.joe; - - - - &a.cokane; - - - - &a.kato; - - - - &a.kris; - - - - &a.kiri; - - - - &a.andreas; - - - - &a.motoyuki; - - - - &a.jkoshy; - - - - &a.kuriyama; - - - - &a.alex; - - - - &a.reg; - - - - &a.jlemon; - - - - &a.truckman; - - - - &a.lile; - - - - &a.kevlo; - - - - &a.scottl; - - - - &a.ade; - - - - &a.jmacd; - - - - &a.smace; - - - - &a.bmah; - - - - &a.dwmalone; - - - - &a.mckay; - - - - &a.mckusick; - - - - &a.ken; - - - - &a.hm; - - - - &a.sanpei; - - - - &a.bmilekic; - - - - &a.non; - - - - &a.jim; - - - - &a.marcel; - - - - &a.dan; - - - - &a.amurai; - - - - &a.markm; - - - - &a.rich; - - - - &a.knu; - - - - &a.nakai; - - - - &a.max; - - - - &a.newton; - - - - &a.rnordier; - - - - &a.davidn; - - - - &a.obrien; - - - - &a.danny; - - - - &a.okazaki; - - - - &a.ljo; - - - - &a.onoe; - - - - &a.marko; - - - - &a.gpalmer; - - - - &a.fsmp; - - - - &a.smpatel; - - - - &a.cp; - - - - &a.wpaul; - - - - &a.alfred; - - - - &a.roam; - - - - &a.wes; - - - - &a.cpiazza; - - - - &a.jdp; - - - - &a.bp; - - - - &a.steve; - - - - &a.mpp; - - - - &a.jraynard; - - - - &a.darrenr; - - - - &a.csgr; - - - - &a.martin; - - - - &a.paul; - - - - &a.roberto; - - - - &a.chuckr; - - - - &a.jesusr; - - - - &a.guido; - - - - &a.groudier; - - - - &a.dima; - - - - &a.asmodai; - - - - &a.ps; - - - - &a.sada; - - - - &a.hrs; - - - - &a.wsanchez; - - - - &a.sos; - - - - &a.nsayer; - - - - &a.wosch; - - - - &a.dick; - - - - &a.jseger; - - - - &a.gshapiro; - - - - &a.simokawa; - - - - &a.vanilla; - - - - &a.shafeeq; - - - - &a.demon; - - - - &a.msmith; - - - - &a.ben; - - - - &a.benno; - - - - &a.des; - - - - &a.sobomax; - - - - &a.dcs; - - - - &a.brian; - - - - &a.mks; - - - - &a.stark; - - - - &a.sumikawa; - - - - &a.murray; - - - - &a.gsutter; - - - - &a.unfurl; - - - - &a.nyan; - - - - &a.tanimura; - - - - &a.taoka; - - - - &a.mtaylor; - - - - &a.dt; - - - - &a.cwt; - - - - &a.pst; - - - - &a.ume; - - - - &a.rv; - - - - &a.hoek; - - - - &a.nectar; - - - - &a.jayanth; - - - - &a.swallace; - - - - &a.takawata; - - - - &a.assar; - - - - &a.dwhite; - - - - &a.nate; - - - - &a.wollman; - - - - &a.joerg; - - - - &a.kbyanc; - - - - &a.yokota; - - - - &a.andy; - - - - &a.phantom; - - - - &a.jmz; - - - - &a.issei; - - - - - - - - Проект Документации FreeBSD - - Проект - Документации FreeBSD ответственен за большое количество - различных подпроектов, каждый подпроект контролируется отдельными - индивидумами и их делегатами (если таковые есть): - - - - Главный Архитектор Проекта Документации - - - &a.nik; - - - - - Webmaster - - - &a.wosch; - - - - - Редактор Руководства - - - &a.jim; - - - - - Редактор ЧаВО - - - &a.faq; - - - - - Редактор Новостей - - - &a.jim; - - - - - Пресс Редактор - - - &a.jkoshy; - - - - - Редактор “Очень-Быстрых” Новостей FreeBSD - - - Chris Coleman chrisc@vmunix.com - - - - - Редактор Галереи FreeBSD - - - &a.phantom; - - - - - Редактор Галереи Коммерческих Разработчиков - - - &a.phantom; - - - - - Редактор Списка Изменений Web сервера - - - &a.www; - - - -]]> - - - Редактор списка Групп Пользователей - - - &a.grog; - - - - - Редактор списка проектов и задач FreeBSD - - - &a.asmodai; - - - - - Проект Java в FreeBSD - - - &a.patrick; - - - - - Конвертация документации из формата LinuxDoc в DocBook - - - &a.nik; - - - - - - - Кто за Что Ответственен - - - - Руководитель - Проекта Документации - - - &a.nik; - - - - - Загрузочные блоки - - - &a.rnordier;, &a.jhb; - - - - - Начальный загрузчик - - - &a.dcs; - &a.jhb; - - - - - Интернационализация - - - &a.ache; - - - - - Postmaster - - - &a.jmb; - - - - - Координатор Релизов FreeBSD - - - &a.jkh; - - - - - Связи с Общественностью - - - &a.jkh; - - - - - Офицер - Безопасности - - - &a.kris; - - - - - Менеджеры - CVS Репозитория - - - &a.peter; - - Помошник: &a.jdp; - - - - - Менеджер - Коллекции Портов FreeBSD - - - &a.asami; - - - - - Стандарты - - - &a.wollman; - - - - - Представитель XFree86 Project, Inc. - - - &a.rich; - - - - - Поддержка в Usenet - - - &a.joerg; - - - - - GNATS - Администратор - - - &a.steve; - - - - - Webmaster - - - &a.wosch; - - - - - - - Официальные участники Проекта Русской Документации FreeBSD - - Это люди, которые имеют права доступа к Репозиторию Проекта - Русской Документации FreeBSD и занимаются переводом существующей - документации на русский язык. - - (в алфавитном порядке, отсортировано по фамилии): - - - - &a.ru.danfe; - - - - &a.ru.ru; - - - - &a.ru.andy; - - - - &a.ru.phantom; - - - - - - - -