Remove old files
This commit is contained in:
Denis Peplin
parent
2282159494
commit
9003d922bc
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=20410
7 changed files with 0 additions and 3856 deletions
|
|
@ -1,468 +0,0 @@
|
|||
<!--
|
||||
éÍÅÎÁ É ÜÌÅËÔÒÏÎÎÙÅ ÁÄÒÅÓÁ ËÏÎÔÒÉÂÕÔÏÒÏ× É CVS ËÏÍÉÔÅÒÏ×.
|
||||
îÁÚ×ÁÎÉÅ ÓÕÝÎÏÓÔÅÊ (entities) ÄÏÌÖÎÙ ÂÙÔØ ÉÄÅÎÔÉÞÎÙ ÉÈ ÌÏÇÉÎÁÍ ÎÁ
|
||||
freefall.FreeBSD.org.
|
||||
|
||||
éÓÐÏÌØÚÕÊÔÅ ÜÔÉ ÓÕÝÎÏÓÔÉ ËÏÇÄÁ ÓÓÙÌÁÅÔÅÓØ ÎÁ ËÏÇÏ-ÌÉÂÏ.
|
||||
|
||||
ðÏÖÁÌÕÊÓÔÁ ÓÏÈÒÁÎÑÊÔÅ ÜÔÏÔ ÓÐÉÓÏË ÏÔÓÏÒÔÉÒÏ×ÁÎÙÍ × ÁÌÆÁ×ÉÔÎÏÍ ÐÏÒÑÄËÅ ÐÏ
|
||||
ÉÍÅÎÁÍ ÓÕÝÎÏÓÔÅÊ.
|
||||
|
||||
The FreeBSD Russian Documentation Project
|
||||
$FreeBSD$
|
||||
$FreeBSDru: frdp/doc/ru_RU.KOI8-R/books/handbook/authors.ent,v 1.2 2000/07/08 13:35:13 phantom Exp $
|
||||
Original revision: 1.80
|
||||
-->
|
||||
|
||||
<!ENTITY a.abial "Andrzej Bialecki <email>abial@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.ache "Andrey A. Chernov <email>ache@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.adam "Adam David <email>adam@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.ade "Ade Lovett <email>ade@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.alc "Alan L. Cox <email>alc@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.alex "Alex Nash <email>alex@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.alfred "Alfred Perlstein <email>alfred@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.amurai "Atsushi Murai <email>amurai@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.andreas "Andreas Klemm <email>andreas@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.andy "Andrey Zakhvatov <email>andy@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.archie "Archie Cobbs <email>archie@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.asami "Satoshi Asami <email>asami@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.asmodai "Jeroen Ruigrok/Asmodai <email>asmodai@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.awebster "Andrew Webster <email>awebster@pubnix.net</email>">
|
||||
|
||||
<!ENTITY a.bde "Bruce Evans <email>bde@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.billf "Bill Fumerola <email>billf@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.bp "Boris Popov <email>bp@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.brandon "Brandon Gillespie <email>brandon@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.brian "Brian Somers <email>brian@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.bsd "Brian S. Dean <email>bsd@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.cawimm "Charles A. Wimmer <email>cawimm@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.cg "Cameron Grant <email>cg@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.charnier "Philippe Charnier <email>charnier@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.chris "Chris Costello <email>chris@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.chuck "Chuck Robey <email>chuckr@glue.umd.edu</email>">
|
||||
|
||||
<!ENTITY a.chuckr "Chuck Robey <email>chuckr@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.cpiazza "Chris Piazza <email>cpiazza@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.cracauer "Martin Cracauer <email>cracauer@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.csgr "Geoff Rehmet <email>csgr@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.cwt "Chris Timmons <email>cwt@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.dan "Dan Moschuk <email>dan@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.danny "Daniel O'Callaghan <email>danny@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.darrenr "Darren Reed <email>darrenr@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.davidn "David Nugent <email>davidn@blaze.net.au</email>">
|
||||
|
||||
<!ENTITY a.dbaker "Daniel Baker <email>dbaker@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.dburr "Donald Burr <email>dburr@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.dcs "Daniel C. Sobral <email>dcs@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.deischen "Daniel Eischen <email>deischen@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.des "Dag-Erling C. Smørgrav <email>des@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.dfr "Doug Rabson <email>dfr@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.dg "David Greenman <email>dg@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.dick "Richard Seaman Jr. <email>dick@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.dillon "Matthew Dillon <email>dillon@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.dima "Dima Ruban <email>dima@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.dirk "Dirk Frömberg <email>dirk@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.dirkvangulik "Dirk-Willem van Gulik <email>Dirk.vanGulik@jrc.it</email>">
|
||||
|
||||
<!ENTITY a.dt "Dmitrij Tejblum <email>dt@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.dufault "Peter Dufault <email>dufault@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.dwhite "Doug White <email>dwhite@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.dyson "John Dyson <email>dyson@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.eivind "Eivind Eklund <email>eivind@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.ejc "Eric J. Chet <email>ejc@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.erich "Eric L. Hernes <email>erich@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.faq "FAQ Maintainer <email>faq@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.fenner "Bill Fenner <email>fenner@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.flathill "Seiichirou Hiraoka <email>flathill@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.foxfair "Howard F. Hu <email>foxfair@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.fsmp "Steve Passe <email>fsmp@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.gallatin "Andrew Gallatin <email>gallatin@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.gclarkii "Gary Clark II <email>gclarkii@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.gehenna "Masahide MAEKAWA <email>gehenna@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.gena "Gennady B. Sorokopud <email>gena@NetVision.net.il</email>">
|
||||
|
||||
<!ENTITY a.ghelmer "Guy Helmer <email>ghelmer@cs.iastate.edu</email>">
|
||||
|
||||
<!ENTITY a.gibbs "Justin T. Gibbs <email>gibbs@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.gioria "Sebastien Gioria <email>gioria@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.gj "Gary Jennejohn <email>gj@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.gpalmer "Gary Palmer <email>gpalmer@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.graichen "Thomas Graichen <email>graichen@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.green "Brian F. Feldman <email>green@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.grog "Greg Lehey <email>grog@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.groudier "Gerard Roudier <email>groudier@club-internet.fr</email>">
|
||||
|
||||
<!ENTITY a.gryphon "Coranth Gryphon <email>gryphon@healer.com</email>">
|
||||
|
||||
<!ENTITY a.gsutter "Gregory Sutter <email>gsutter@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.guido "Guido van Rooij <email>guido@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.hanai "Hiroyuki HANAI <email>hanai@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.handy "Brian N. Handy <email>handy@sxt4.physics.montana.edu</email>">
|
||||
|
||||
<!ENTITY a.roger "Roger Hardiman <email>roger@freebsd.org</email>">
|
||||
|
||||
<!ENTITY a.helbig "Wolfgang Helbig <email>helbig@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.hm "Hellmuth Michaelis <email>hm@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.hoek "Tim Vanderhoek <email>hoek@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.hosokawa "Tatsumi Hosokawa <email>hosokawa@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.hsu "Jeffrey Hsu <email>hsu@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.imp "Warner Losh <email>imp@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.imura "Ryuichiro IMURA <email>imura@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.itojun "Jun-ichiro Itoh <email>itojun@itojun.org</email>">
|
||||
|
||||
<!ENTITY a.iwasaki "Mitsuru IWASAKI <email>iwasaki@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jasone "Jason Evans <email>jasone@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jb "John Birrell <email>jb@cimlogic.com.au</email>">
|
||||
|
||||
<!ENTITY a.jdp "John Polstra <email>jdp@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jedgar "Chris D. Faulhaber <email>jedgar@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jehamby "Jake Hamby <email>jehamby@lightside.com</email>">
|
||||
|
||||
<!ENTITY a.jesusr "Jesus Rodriguez <email>jesusr@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jfieber "John Fieber <email>jfieber@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jfitz "James FitzGibbon <email>jfitz@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jhay "John Hay <email>jhay@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jhb "John Baldwin <email>jhb@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jhs "Julian Stacey <email>jhs@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jim "Jim Mock <email>jim@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jkh "Jordan K. Hubbard <email>jkh@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jkoshy "Joseph Koshy <email>jkoshy@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jlemon "Jonathan Lemon <email>jlemon@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jlind "John Lind <email>john@starfire.MN.ORG</email>">
|
||||
|
||||
<!ENTITY a.jlrobin "James L. Robinson <email>jlrobin@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jmacd "Joshua Peck Macdonald <email>jmacd@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jmas "Jose M. Alcaide <email>jmas@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jmb "Jonathan M. Bresler <email>jmb@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jmg "John-Mark Gurney <email>jmg@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jmz "Jean-Marc Zucconi <email>jmz@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.joe "Josef Karthauser <email>joe@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.joerg "Jörg Wunsch <email>joerg@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.john "John Cavanaugh <email>john@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jraynard "James Raynard <email>jraynard@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jseger "Justin Seger <email>jseger@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.julian "Julian Elischer <email>julian@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jvh "Johannes Helander <email>jvh@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.karl "Karl Strickland <email>karl@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.kato "Takenori KATO <email>kato@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.kelly "Sean Kelly <email>kelly@ad1440.net</email>">
|
||||
|
||||
<!ENTITY a.ken "Kenneth D. Merry <email>ken@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.kevlo "Kevin Lo <email>kevlo@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.kjc "Kenjiro Cho <email>kjc@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.knu "Akinori MUSHA <email>knu@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.kris "Kris Kennaway <email>kris@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.kuriyama "Jun Kuriyama <email>kuriyama@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.lars "Lars Fredriksen <email>lars@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.lile "Larry Lile <email>lile@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.ljo "L Jonas Olsson <email>ljo@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.luoqi "Luoqi Chen <email>luoqi@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.marcel "Marcel Moolenaar <email>marcel@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.markm "Mark Murray <email>markm@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.martin "Martin Renters <email>martin@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.max "Masafumi NAKANE <email>max@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.mayo "Mark Mayo <email>mark@vmunix.com</email>">
|
||||
|
||||
<!ENTITY a.mbarkah "Ade Barkah <email>mbarkah@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.mckay "Stephen McKay <email>mckay@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.mckusick "Kirk McKusick <email>mckusick@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.md "Mark Dapoz <email>md@bsc.no</email>">
|
||||
|
||||
<!ENTITY a.mdodd "Matthew N. Dodd <email>winter@jurai.net</email>">
|
||||
|
||||
<!ENTITY a.mharo "Michael Haro <email>mharo@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.mjacob "Matthew Jacob <email>mjacob@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.mks "Mike Spengler <email>mks@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.motoyuki "Motoyuki Konno <email>motoyuki@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.mph "Matthew Hunt <email>mph@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.mpp "Mike Pritchard <email>mpp@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.msmith "Michael Smith <email>msmith@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.mtaylor "Mark J. Taylor <email>mtaylor@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.murray "Murray Stokely <email>murray@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.nakai "Yukihiro Nakai <email>nakai@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.nate "Nate Williams <email>nate@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.nbm "Neil Blakey-Milner <email>nbm@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.nectar "Jacques Vidrine <email>nectar@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.newton "Mark Newton <email>newton@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.nhibma "Nick Hibma <email>n_hibma@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.nik "Nik Clayton <email>nik@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.nsayer "Nick Sayer <email>nsayer@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.nsj "Nate Johnson <email>nsj@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.nyan "Yoshihiro Takahashi <email>nyan@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.obrien "David O'Brien <email>obrien@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.olah "Andras Olah <email>olah@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.opsys "Chris Watson <email>opsys@open-systems.net</email>">
|
||||
|
||||
<!ENTITY a.patrick "Patrick S. Gardella <email>patrick@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.paul "Paul Richards <email>paul@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.pb "Pierre Beyssac <email>pb@fasterix.freenix.org</email>">
|
||||
|
||||
<!ENTITY a.pds "Peter da Silva <email>pds@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.peter "Peter Wemm <email>peter@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.phantom "Alexey Zelkin <email>phantom@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.phk "Poul-Henning Kamp <email>phk@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.pho "Peter Holm <email>pho@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.piero "Piero Serini <email>piero@strider.inet.it</email>">
|
||||
|
||||
<!ENTITY a.pjc "Peter Childs <email>pjchilds@imforei.apana.org.au</email>">
|
||||
|
||||
<!ENTITY a.proven "Chris Provenzano <email>proven@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.ps "Paul Saab <email>ps@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.pst "Paul Traina <email>pst@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.reg "Jeremy Lea <email>reg@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.rgrimes "Rodney Grimes <email>rgrimes@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.rhuff "Robert Huff <email>rhuff@cybercom.net</email>">
|
||||
|
||||
<!ENTITY a.ricardag "Ricardo AG <email>ricardag@ag.com.br</email>">
|
||||
|
||||
<!ENTITY a.rich "Rich Murphey <email>rich@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.rnordier "Robert Nordier <email>rnordier@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.roberto "Ollivier Robert <email>roberto@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.rse "Ralf S. Engelschall <email>rse@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.ru "Ruslan Ermilov <email>ru@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.rwatson "Robert Watson <email>rwatson@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.sada "Kenji SADA <email>sada@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.scrappy "Marc G. Fournier <email>scrappy@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.se "Stefan Esser <email>se@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.sef "Sean Eric Fagan <email>sef@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.sheldonh "Sheldon Hearn <email>sheldonh@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.shige "Shigeyuki Fukushima <email>shige@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.shin "Yoshinobu Inoue <email>shin@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.simokawa "Hidetoshi Shimokawa <email>simokawa@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.smace "Scott Mace <email>smace@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.smpatel "Sujal Patel <email>smpatel@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.sos "Søren Schmidt <email>sos@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.stark "Gene Stark <email>stark@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.stb "Stefan Bethke <email>stb@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.steve "Steve Price <email>steve@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.sumikawa "Munechika Sumikawa <email>sumikawa@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.swallace "Steven Wallace <email>swallace@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.tanimura "Seigo Tanimura <email>tanimura@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.taoka "Satoshi Taoka <email>taoka@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.tedm "Ted Mittelstaedt <email>tedm@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.tegge "Tor Egge <email>tegge@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.tg "Thomas Gellekum <email>tg@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.thepish "Peter Hawkins <email>thepish@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.tom "Tom Hukins <email>tom@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.torstenb "Torsten Blum <email>torstenb@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.truckman "Don “Truck” Lewis <email>truckman@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.ugen "Ugen J.S.Antsilevich <email>ugen@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.uhclem "Frank Durda IV <email>uhclem@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.ulf "Ulf Zimmermann <email>ulf@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.ume "Hajimu UMEMOTO <email>ume@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.unfurl "Bill Swingle <email>unfurl@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.vanilla "Vanilla I. Shu <email>vanilla@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.wes "Wes Peters <email>wes@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.whiteside "Don Whiteside <email>whiteside@acm.org</email>">
|
||||
|
||||
<!ENTITY a.wilko "Wilko Bulte <email>wilko@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.will "Will Andrews <email>will@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.wlloyd "Bill Lloyd <email>wlloyd@mpd.ca</email>">
|
||||
|
||||
<!ENTITY a.wollman "Garrett Wollman <email>wollman@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.wosch "Wolfram Schneider <email>wosch@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.wpaul "Bill Paul <email>wpaul@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.wsanchez "Wilfredo Sánchez <email>wsanchez@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.yokota "Kazutaka YOKOTA <email>yokota@FreeBSD.org</email>">
|
||||
|
||||
|
||||
<!-- Mailing Lists -->
|
||||
<!ENTITY a.www "FreeBSD Webmaster Mailing List <email>www@FreeBSD.org</email>">
|
||||
|
||||
|
|
@ -1,802 +0,0 @@
|
|||
<!--
|
||||
The FreeBSD Russian Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDru: frdp/doc/ru_RU.KOI8-R/books/handbook/backups/chapter.sgml,v 1.3 2000/10/10 18:48:30 phantom Exp $
|
||||
Original revision: 1.26
|
||||
-->
|
||||
|
||||
<chapter id="backups">
|
||||
<title>Резервное копирование</title>
|
||||
|
||||
<sect1>
|
||||
<title>Описание</title>
|
||||
|
||||
<para>В следующей главе будут описаны методы резервного копирования данных
|
||||
и используемые для этого программы. Если вы хотите добавить что-то в
|
||||
этот раздел, пошлите ваш текст на адрес &a.doc;.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="backups-tapebackups">
|
||||
<title>Носители на магнитной ленте</title>
|
||||
|
||||
<para>К наиболее часто используемым носителям на магнитной ленте следует
|
||||
отнести ленты шириной 4мм и 8мм, а также типа QIC, мини-картриджи и
|
||||
DLT.</para>
|
||||
|
||||
<sect2 id="backups-tapebackups-4mm">
|
||||
<title>4мм (DDS: Digital Data Storage)</title>
|
||||
|
||||
<para>Ленты шириной 4мм заменяют QIC в качестве наиболее
|
||||
предпочтительного носителя для создания резервных копий. Эта тенденция
|
||||
значительно усилилась после покупки компанией Conner фирмы Archive,
|
||||
ведущего производителя накопителей QIC и последующего прекращения
|
||||
их выпуска. Накопители 4мм малы по размеру и мало шумят, но у них нет
|
||||
репутации носителя, обладающего надежностью приводов 8мм. Картриджи
|
||||
более дешевы и меньше по размеру (3 x 2 x 0.5 дюймов, 76 x 51 x 12 мм),
|
||||
чем 8мм-картриджи. Накопители для лент шириной 4мм, как и 8мм, имеют
|
||||
сравнительно малый срок службы головок, по причине использования в
|
||||
обоих случаях технологии спирального сканирования (helical
|
||||
scan).</para>
|
||||
|
||||
<para>Пропускная способность у таких накопителей начинается с цифры
|
||||
~150kB/s, пиковая достигает ~500kB/s. Емкость накопителей начинается с
|
||||
1.3 GB и может достигать 2.0 GB. Аппаратное сжатие, имеющееся на
|
||||
большинстве таких накопителей, дает увеличение емкости примерно вдвое.
|
||||
Блоки многоприводных ленточных библиотек могут иметь до 6 накопителей
|
||||
в одном модуле с автоматической сменой ленты. Емкость библиотек может
|
||||
достигать 240 GB.</para>
|
||||
|
||||
<para>Стандарт DDS-3 в настоящее время поддерживает емкость вплоть до
|
||||
12GB (или 24GB сжатой информации).</para>
|
||||
|
||||
<para>В накопителях 4мм, как и в приводах 8мм, используется технология
|
||||
спирального сканирования. Все плюсы и минусы этой технологии относятся
|
||||
как к 4мм, так и 8мм приводам.</para>
|
||||
|
||||
<para>Не следует использовать ленты после того, как они были подвергнуты
|
||||
2000 проходов, или были использованы для создания 100 полных
|
||||
копий.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="backups-tapebackups-8mm">
|
||||
<title>8мм (Exabyte)</title>
|
||||
|
||||
<para>Ленты шириной 8мм являются самым распространенным типом для
|
||||
ленточных SCSI-накопителей; они же являются наиболее удачным выбором
|
||||
при выборе типа носителей для обмена лентами. Наверное, каждый сервер
|
||||
имеет привод шириной 8мм. Эти приводы удобны, они работают надежно и
|
||||
тихо. Картриджи дешевы и малы по размеру (4.8 x 3.3 x 0.6 дюймов;
|
||||
122 x 84 x 15 мм). Одним минусом лент шириной 8мм является
|
||||
сравнительно малое время службы головок и лент из-за высокой скорости
|
||||
движения ленты вдоль головок.</para>
|
||||
|
||||
<para>Скорость передачи данных варьируется от ~250kB/s до ~500kB/s.
|
||||
Объем хранимых данных начинается с 300МБ и может достигать 7ГБ.
|
||||
Аппаратное сжатие, имеющееся практически на всех таких приводах,
|
||||
увеличивает емкость примерно вдвое. Эти приводы существуют как в виде
|
||||
отдельных модулей, так и в виде многоприводных ленточных библиотек с
|
||||
6 приводами и 120 лентами в одном отсеке. Ленты сменяются
|
||||
автоматически модулем. Емкости библиотек достигают величин,
|
||||
превышающих 840 ГБ.</para>
|
||||
|
||||
<para>Модель Exabyte <quote>Mammoth</quote> поддерживает емкость ленты в
|
||||
12ГБ (25ГБ со сжатием) и стоит примерно вдвое больше, чем обычный
|
||||
ленточный накопитель.</para>
|
||||
|
||||
<para>Данные на ленту записываются по технологии спирального
|
||||
сканирования, головки позиционируются под углом к носителю (примерно в
|
||||
6 градусов). Лента оборачивается на 270 градусов вокруг шпульки,
|
||||
которая держит головки. Во время скольжения ленты вокруг шпульки
|
||||
последняя вращается. В результате достигается высокая плотность записи
|
||||
данных с очень близко лежащими дорожками, расположенными под наклоном
|
||||
по всей ленте.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="backups-tapebackups-qic">
|
||||
<title>QIC</title>
|
||||
|
||||
<para>Ленты и накопители формата QIC-150, наверное, являются наиболее
|
||||
распространенным типом носителей. Приводы лент формата QIC являются
|
||||
самыми дешевыми "серьезными" накопителями для резервного копирования.
|
||||
Минусом является стоимость носителей. Ленты формата QIC по сравнению
|
||||
с лентами шириной 8мм или 4мм являются дорогими, превосходя их по
|
||||
стоимости хранения одного гигабайта в пять раз. Однако если вам
|
||||
будут достаточно половины ленты, QIC может оказаться правильным
|
||||
выбором. QIC является <emphasis>самым</emphasis> распространенным
|
||||
типом привода. Каждый сайт имеет привод QIC какой-либо емкости. QIC
|
||||
имеет большое количество плотностей на физически похожих (иногда
|
||||
даже идентичных) лентах. Приводы QIC работают вовсе не тихо. Эти
|
||||
накопители громко осуществляют поиск перед тем, как начать запись
|
||||
данных и достаточно шумны в процессе чтения, записи или поиска. Ленты
|
||||
QIC имеют размеры (6 x 4 x 0.7 дюймов; 15.2 x 10.2 x 1.7 мм). <link
|
||||
linkend="backups-tapebackups-mini">Мини-картриджи</link>, в которых
|
||||
также используется лента шириной 1/4", обсуждаются отдельно.
|
||||
Библиотек лент и роботов для их замены не существует.</para>
|
||||
|
||||
<para>Скорость обмена данными лежит в границах от ~150kB/s до ~500kB/s.
|
||||
Емкость накопителей варьируется от 40 МБ до 15 ГБ. Аппаратное сжатие
|
||||
присутствует во многих современных накопителях QIC. Приводы QIC
|
||||
устанавливаются менее часто; они вытесняются накопителями DAT.</para>
|
||||
|
||||
<para>На ленту данные записываются в виде дорожек. Дорожки располагаются
|
||||
в длину вдоль всей ленты. Количество дорожек, и, в свою очередь, их
|
||||
ширина, меняется вместе с емкостью ленты. Большинство, если не все
|
||||
современные накопители обеспечивают обратную совместимость по крайней
|
||||
мере для чтения (однако зачастую и для режима записи). Формат QIC
|
||||
имеет хорошую репутацию в области надежности хранения данных (механика
|
||||
устроена проще и более надежна, чем в случае накопителей, построенных
|
||||
по технологии спирального сканирования).</para>
|
||||
|
||||
<para>Ленты не следует больше использовать после создания 5,000 резервных
|
||||
копий.</para>
|
||||
</sect2>
|
||||
|
||||
<![ %not.published; [
|
||||
|
||||
<sect2 id="backups-tapebackups-mini">
|
||||
<title>* Мини-картриджи</title>
|
||||
|
||||
<para></para>
|
||||
</sect2>
|
||||
|
||||
]]>
|
||||
|
||||
<sect2 id="backups-tapebackups-dlt">
|
||||
<title>DLT</title>
|
||||
|
||||
<para>Формат DLT обладает самой высокой скоростью передачи данных среди
|
||||
всех перечисленных здесь накопителей. Лента шириной 1/2" (12.5мм)
|
||||
помещена в один картридж с катушкой (4 x 4 x 1 дюймов; 100 x 100 x
|
||||
25 мм). Вдоль одной из сторон картриджа расположена сдвигающаяся
|
||||
крышечка. Механизм накопителя открывает эту крышку, чтобы вытащить
|
||||
конец ленты. На этом конце имеется овальное отверстие, которое
|
||||
используется для "захвата" ленты. Принимающая катушка размещена внутри
|
||||
накопителя. Все другие типы картриджей, перечисленные здесь (за
|
||||
исключением 9-дорожечных лент), имеют как подающий, так и принимающий
|
||||
барабаны внутри самого картриджа.</para>
|
||||
|
||||
<para>Скорость передачи данных равна примерно 1.5MB/s, что в три раза
|
||||
больше скорости передачи данных для накопителей 4мм, 8мм или QIC.
|
||||
Емкость картриджей варьируется от 10ГБ до 20ГБ для одного накопителя.
|
||||
Приводы могут компоноваться как многоленточные роботизированные, так
|
||||
и многоленточные, многоприводные библиотеки лент, вмещающие от 5 до
|
||||
900 лент и от 1 до 20 приводов, что дает емкость хранилища от 50ГБ до
|
||||
9ТБ.</para>
|
||||
|
||||
<para>Формат DLT Type IV поддерживает емкость до 70ГБ со сжатием.</para>
|
||||
|
||||
<para>Данные на ленту записываются в виде дорожек, параллельных
|
||||
направлению движения (точно также, как и для лент QIC). Одновременно
|
||||
записываются две дорожки. Срок жизни головок чтения/записи
|
||||
сравнительно велик; как только лента перестает двигаться, одновременно
|
||||
прекращается трение между головками и лентой.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title id="backups-tapebackups-ait">AIT</title>
|
||||
|
||||
<para>AIT - это новый формат фирмы Sony, который позволяет хранить до
|
||||
50ГБ (со сжатием) информации на одной ленте. Ленты содержат микросхемы
|
||||
памяти, на которых размещается каталог содержимого ленты. Этот каталог
|
||||
может быть быстро считан накопителем для определения расположения
|
||||
файлов на ленте, вместо того, чтобы тратить несколько минут на поиск,
|
||||
как это происходит с другими форматами. Такое программное обеспечение,
|
||||
как SAMS:Alexandria, может управлять сорока или большим количеством
|
||||
ленточных библиотек AIT, связываясь непосредственно с памятью лент для
|
||||
вывода их содержимого, определения того, какие файлы были скопированы
|
||||
на какую ленту, выбора нужной ленты, ее загрузки и восстановления
|
||||
данных с ленты.</para>
|
||||
|
||||
<para>Библиотеки с такими функциями стоят в районе $20,000, выводя их из
|
||||
ниши любительского рынка.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Использование новой ленты первый раз</title>
|
||||
|
||||
<para>Если вы попытаетесь прочитать или записать новую, абсолютно чистую
|
||||
ленту, в первый раз, то вам это не удастся. Выводимые на консоль
|
||||
сообщения будут выглядеть примерно так:</para>
|
||||
|
||||
<screen>
|
||||
sa0(ncr1:4:0): NOT READY asc:4,1
|
||||
sa0(ncr1:4:0): Logical unit is in process of becoming ready
|
||||
</screen>
|
||||
|
||||
<para>На ленте отсутствует идентификационный блок (блок номер 0). Со
|
||||
времен принятия стандарта QIC-525 все накопители формата QIC записывают
|
||||
на ленту идентификационный блок (Identifier Block). Здесь имеется два
|
||||
решения:</para>
|
||||
|
||||
<para>По команде <command>mt fsf 1</command> ленточный накопитель
|
||||
записывает идентификационный блок на ленту.</para>
|
||||
|
||||
<para>Воспользуйтесь кнопкой на передней панели для выброса ленты.</para>
|
||||
|
||||
<para>Вставьте ленту повторно и по команде &man.dump.8; сбросьте данные
|
||||
на ленту.</para>
|
||||
|
||||
<para>Команда &man.dump.8; выдаст <literal>DUMP: End of tape
|
||||
detected</literal>, а на консоли будет выведено: <literal>HARDWARE
|
||||
FAILURE info:280 asc:80,96</literal></para>
|
||||
|
||||
<para>перемотайте ленту такой командой:
|
||||
<command>mt rewind</command></para>
|
||||
|
||||
<para>Последующие операции с лентой будут успешными.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="backup-programs">
|
||||
<title>Программы резервного копирования</title>
|
||||
|
||||
<para>Тремя основными программами являются &man.dump.8;, &man.tar.1; и
|
||||
&man.cpio.1;.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Dump и Restore</title>
|
||||
|
||||
<para>&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). Для
|
||||
использования емкостей нынешних накопителей на магнитной ленте эти
|
||||
параметры могут быть заданы в командной строке.</para>
|
||||
|
||||
<para>&man.rdump.8; и &man.rrestore.8; предназначены для резервного
|
||||
копирования данных по сети на накопитель, подключенный к другому
|
||||
компьютеру. Обе программы используют в работе &man.rcmd.3; и
|
||||
&man.ruserok.3; для доступа к накопителю на магнитной ленте на
|
||||
удаленном компьютере. Поэтому пользователь, выполняющий резервное
|
||||
копирование, должен иметь доступ к удаленному компьютеру через
|
||||
<literal>rhosts</literal>. Аргументы для &man.rdump.8; и
|
||||
&man.rrestore.8; должны подходить для использования на другом
|
||||
компьютере. (Например, при выполнении копирования по команде
|
||||
<command>rdump</command> на компьютере с FreeBSD на накопитель Exabyte,
|
||||
подключенный к машине Sun по имени <hostid>komodo</hostid>, используйте
|
||||
такую команду: <command>/sbin/rdump 0dsbfu 54000 13000 126
|
||||
komodo:/dev/nrsa8 /dev/rda0a 2>&1</command>) Будьте осторожны:
|
||||
есть проблемы с обеспечением безопасности при разрешении использования
|
||||
команд <literal>rhosts</literal>. Внимательно отнеситесь к вашей
|
||||
ситуации.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Tar</title>
|
||||
|
||||
<para>Утилита &man.tar.1; также восходит корнями к Version 6 системы ATT
|
||||
Unix (около 1975). &man.tar.1; работает с файловой системой;
|
||||
&man.tar.1; записывает на ленту файлы и каталоги. &man.tar.1;
|
||||
поддерживает не полный набор опций, имеющихся в &man.cpio.1;, однако
|
||||
он не требует необычного перенаправления в командной строке, которое
|
||||
используется в утилите &man.cpio.1;.</para>
|
||||
|
||||
<para>В большинстве версий &man.tar.1; создание резервных копий по сети
|
||||
не поддерживается. Версия GNU утилиты &man.tar.1;, которая
|
||||
используется во FreeBSD, поддерживает удаленные устройства в том же
|
||||
самом синтаксисе, что и &man.rdump.8;. Чтобы скопировать данные на
|
||||
накопитель Exabyte, подключенный к машине Sun по имени
|
||||
<hostid>komodo</hostid>, используйте такую команду:
|
||||
<command>/usr/bin/tar cf komodo:/dev/nrsa8 . 2>&1</command>. В
|
||||
случае использования версий без поддержки удаленных устройств, вы
|
||||
можете воспользоваться перенаправлением вывода и командой &man.rsh.1;
|
||||
для посылки данных на удаленный ленточный накопитель.</para>
|
||||
|
||||
<screen>
|
||||
&prompt.root; <userinput>tar cf - . | rsh <replaceable>hostname</replaceable> dd of=<replaceable>tape-device</replaceable> obs=20b</userinput>
|
||||
</screen>
|
||||
|
||||
<para>Если вы беспокоитесь о безопасности создания резервных копий по
|
||||
сети, то вместо &man.rsh.1; вам нужно использовать &man.ssh.1;.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Cpio</title>
|
||||
|
||||
<para>&man.cpio.1; является оригинальной программой Unix для обмена
|
||||
файлами на магнитных носителях. В утилите &man.cpio.1; имеются опции
|
||||
(кроме всего прочего), позволяющие выполнять изменение порядка
|
||||
следования байтов, поддерживающие различные форматы архивов и
|
||||
выполняющие перенаправление данных другим программам. Последняя
|
||||
возможность делает &man.cpio.1; прекрасным выбором для целей установки.
|
||||
&man.cpio.1; не знает о том, как работать с каталогами, список файлов
|
||||
должен даваться через <filename>stdin</filename>.</para>
|
||||
|
||||
<para>&man.cpio.1; не поддерживает создание резервных копий по сети. Вы
|
||||
можете воспользоваться перенаправлением вывода и программой &man.rsh.1;
|
||||
для посылки данных на удаленный накопитель. (XXX добавить пример
|
||||
использования утилиты)</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Pax</title>
|
||||
|
||||
<para>&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;.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="backups-programs-amanda">
|
||||
<title>Amanda</title>
|
||||
|
||||
<para><ulink url="../ports/misc.html#amanda-2.4.0">Amanda</ulink>
|
||||
(Advanced Maryland Network Disk Archiver) является целой
|
||||
клиент/серверной системой резервного копирования, а не отдельной
|
||||
программой. Сервер Amanda сможет осуществлять резервное копирование
|
||||
на единственный накопитель любого количества компьютеров, на которых
|
||||
имеется клиент Amanda и которые могут связываться по сети с сервером
|
||||
Amanda. Общей проблемой систем с большим количеством больших дисков
|
||||
является время, требуемое для непосредственной записи данных на ленту,
|
||||
превышающее лимит времени, выделенный на эту задачу. Amanda решает
|
||||
эту проблему. Amanda может использовать "промежуточный диск" для
|
||||
резервного копирования нескольких файловых систем одновременно. Amanda
|
||||
создает "наборы архивов": группа лент, используемых в некоторый период
|
||||
времени для создания полных копий всех файловых систем, перечисленных
|
||||
в конфигурационном файле системы Amanda. "Архивный набор" содержит
|
||||
также создаваемый каждую ночь инкрементальные (или дифференциальные)
|
||||
резервные копии всех файловых систем. Восстановление поврежденной
|
||||
файловой системы требует наличие самой последней полной копии и
|
||||
инкрементальных резервных копий.</para>
|
||||
|
||||
<para>Конфигурационный файл дает прекрасный механизм управление процессом
|
||||
резервного копирования и объемом трафика, генерируемого системой
|
||||
Amanda. Amanda сможет использовать любую из перечисленных выше
|
||||
программ для записи данных на ленту. Amanda имеется в виде как порта,
|
||||
так и пакаджа, и по умолчанию она не установлена.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Не делать ничего</title>
|
||||
|
||||
<para><quote>Не делать ничего</quote> - это не программа для компьютера,
|
||||
и в то же время это наиболее широко используемая стратегия резервного
|
||||
копирования. Здесь нет никаких первоначальных затрат. Здесь нет
|
||||
расписания, которому нужно следовать. Просто скажите нет. Если что-то
|
||||
случится с вашими данными, улыбнитесь и забудьте о них!</para>
|
||||
|
||||
<para>Если ваше время и данные практически ничего не стоят, то <quote>не
|
||||
делать ничего</quote> является самой подходящей программой для вашего
|
||||
компьютера. Но будьте осторожны, Unix является весьма полезным
|
||||
инструментом, и через полгода вы можете обнаружить, что у вас есть
|
||||
набор файлов, представляющих для вас определенную ценность.</para>
|
||||
|
||||
<para><quote>Ничего не делать</quote> является правильным методом
|
||||
резервного копирования для <filename>/usr/obj</filename> и других
|
||||
деревьев каталогов, которые могут быть в точности перегенерированы
|
||||
вашим компьютером. Примером являются файлы, представляющие страницы
|
||||
этой книги - они генерируются из входных файлов
|
||||
<acronym>SGML</acronym>. Создание резервных копий файлов
|
||||
<acronym>HTML</acronym> не нужно. Исходные файлы
|
||||
<acronym>SGML</acronym> копируются регулярно.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Какая программа резервного копирования самая лучшая?</title>
|
||||
|
||||
<para>&man.dump.8; <emphasis>Точка.</emphasis> Elizabeth D. Zwicky
|
||||
протестировала все программы резервного копирования, обсуждаемые здесь.
|
||||
Беспроигрышным вариантом для сохранения всех ваших данных и
|
||||
особенностей файловых систем Unix является &man.dump.8;. Элизабет
|
||||
создала файловые системы, содержащие большое количество необычных
|
||||
элементов (и некоторых не так уж необычных) и тестировала каждую из
|
||||
программ, выполняя резервное копирование и последующее восстановление
|
||||
этих файловых систем. В число необычных элементов входили: файлы с
|
||||
дырами, файлы с дырами и блоком пустого места, файлы с необычными
|
||||
символами в их именах, нечитаемые и незаписываемые файлы, устройства,
|
||||
меняющие свой размер во время резервного копирования, файлы,
|
||||
создаваемые и удаляемые во время копирования и тому подобное. Она
|
||||
представила результаты на конференции LISA V в октябре 1991 года.
|
||||
Посмотрите ссылку на <ulink
|
||||
url="http://reality.sgi.com/zwicky_neu/testdump.doc.html">
|
||||
torture-testing Backup and Archive Programs</ulink>.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Процедура восстановления при сбое</title>
|
||||
|
||||
<sect3>
|
||||
<title>До того, как случится катастрофа</title>
|
||||
|
||||
<para>Вам нужно выполнить всего лишь четыре шага для того, чтобы быть
|
||||
готовым к любому сбою.</para>
|
||||
|
||||
<para>Во-первых, распечатайте разметку диска для всех ваших дисков
|
||||
(<command>например, disklabel da0 | lpr</command>), таблицу файловых
|
||||
систем (<filename>/etc/fstab</filename>) и все сообщения, выводимые
|
||||
при загрузке, каждого по два экземпляра.</para>
|
||||
|
||||
<para>Во-вторых, определите, все ли устройства присутствуют на
|
||||
загрузочной и аварийной дискетах (<filename>boot.flp</filename> и
|
||||
<filename>fixit.flp</filename>). Самым простым способом проверки
|
||||
является перезагрузка вашей машины с загрузочной дискетой,
|
||||
вставленной в дисковод и последующая проверка сообщений при загрузке.
|
||||
Если все имеющиеся у вас устройства здесь будут перечислены и будут
|
||||
работоспособны, перейдите к третьему шагу.</para>
|
||||
|
||||
<para>В противном случае вам необходимо будет создать две особым
|
||||
образом сформированные загрузочные дискеты, на которых помещено
|
||||
ядро, могущее смонтировать все ваши диски и получить доступ к вашему
|
||||
стримеру. На этих дискетах должны быть: &man.fdisk.8;,
|
||||
&man.disklabel.8;, &man.newfs.8;, &man.mount.8; и какая-либо
|
||||
используемая вами программа резервного копирования. Эти программы
|
||||
должны быть скомпонованы статически. Если вы используете
|
||||
&man.dump.8;, то на дискете должна присутствовать и программа
|
||||
&man.restore.8;.</para>
|
||||
|
||||
<para>В-третьих, регулярно создавайте резервные копии на ленте. Любые
|
||||
изменения, которые вы делали после последнего резервного копирования,
|
||||
могут быть безвозвратно потеряны. На лентах включайте защиту от
|
||||
записи.</para>
|
||||
|
||||
<para>В-четвертых, проверяйте работу дискет (либо
|
||||
<filename>boot.flp</filename> и <filename>fixit.flp</filename>, либо
|
||||
двух дискет, которые вы сделали при выполнении второго шага) и лент
|
||||
с резервными копиями. Ведите журнал выполняемых действий. Храните
|
||||
эти записи вместе с загрузочной дискетой, распечатками и лентами.
|
||||
Вы просто обезумеете при восстановлении данных, если окажется, что
|
||||
записи могли бы избежать разрушения ваших резервных копий (Каким
|
||||
образом? Вместо команды <command>tar xvf /dev/rsa0</command> вы
|
||||
могли случайно набрать <command>tar cvf /dev/rsa0</command> и тем
|
||||
самым перезаписать вашу резервную копию).</para>
|
||||
|
||||
<para>Для дополнительной страховки, каждый раз создавайте загрузочные
|
||||
дискеты и две резервные копии на ленте. Храните одну из копий в
|
||||
каком-то удаленном месте и НЕ в том же здании, где находится ваш
|
||||
офис. Достаточно большое количество компаний во Всемирном Торговом
|
||||
Центре изучило это на своей шкуре. Это удаленное хранилище должно
|
||||
быть физически отделено на большое расстояние от ваших компьютеров и
|
||||
дисковых устройств.</para>
|
||||
|
||||
<para>Пример скрипта для создания загрузочной дискеты:</para>
|
||||
|
||||
<programlisting>
|
||||
<![ CDATA [#!/bin/sh
|
||||
#
|
||||
# create a restore floppy
|
||||
#
|
||||
# format the floppy
|
||||
#
|
||||
PATH=/bin:/sbin:/usr/sbin:/usr/bin
|
||||
|
||||
fdformat -q fd0
|
||||
if [ $? -ne 0 ]
|
||||
then
|
||||
echo "Bad floppy, please use a new one"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# place boot blocks on the floppy
|
||||
#
|
||||
disklabel -w -B /dev/rfd0c fd1440
|
||||
|
||||
#
|
||||
# newfs the one and only partition
|
||||
#
|
||||
newfs -t 2 -u 18 -l 1 -c 40 -i 5120 -m 5 -o space /dev/rfd0a
|
||||
|
||||
#
|
||||
# mount the new floppy
|
||||
#
|
||||
mount /dev/fd0a /mnt
|
||||
|
||||
#
|
||||
# create required directories
|
||||
#
|
||||
mkdir /mnt/dev
|
||||
mkdir /mnt/bin
|
||||
mkdir /mnt/sbin
|
||||
mkdir /mnt/etc
|
||||
mkdir /mnt/root
|
||||
mkdir /mnt/mnt # for the root partition
|
||||
mkdir /mnt/tmp
|
||||
mkdir /mnt/var
|
||||
|
||||
#
|
||||
# populate the directories
|
||||
#
|
||||
if [ ! -x /sys/compile/MINI/kernel ]
|
||||
then
|
||||
cat << EOM
|
||||
The MINI kernel does not exist, please create one.
|
||||
Here is an example config file:
|
||||
#
|
||||
# MINI -- A kernel to get FreeBSD on onto a disk.
|
||||
#
|
||||
machine "i386"
|
||||
cpu "I486_CPU"
|
||||
ident MINI
|
||||
maxusers 5
|
||||
|
||||
options INET # needed for _tcp _icmpstat _ipstat
|
||||
# _udpstat _tcpstat _udb
|
||||
options FFS #Berkeley Fast File System
|
||||
options FAT_CURSOR #block cursor in syscons or pccons
|
||||
options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device
|
||||
options NCONS=2 #1 virtual consoles
|
||||
options USERCONFIG #Allow user configuration with -c XXX
|
||||
|
||||
config kernel root on da0 swap on da0 and da1 dumps on da0
|
||||
|
||||
controller isa0
|
||||
controller pci0
|
||||
|
||||
controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
|
||||
disk fd0 at fdc0 drive 0
|
||||
|
||||
controller ncr0
|
||||
|
||||
controller scbus0
|
||||
|
||||
device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr
|
||||
device npx0 at isa? port "IO_NPX" irq 13 vector npxintr
|
||||
|
||||
device da0
|
||||
device da1
|
||||
device da2
|
||||
|
||||
device sa0
|
||||
|
||||
pseudo-device loop # required by INET
|
||||
pseudo-device gzip # Exec gzipped a.out's
|
||||
EOM
|
||||
exit 1
|
||||
fi
|
||||
|
||||
cp -f /sys/compile/MINI/kernel /mnt
|
||||
|
||||
gzip -c -best /sbin/init > /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 <<EOM
|
||||
/dev/fd0a / ufs rw 1 1
|
||||
EOM
|
||||
|
||||
#
|
||||
# create minimum passwd file
|
||||
#
|
||||
cat > /mnt/etc/passwd <<EOM
|
||||
root:*:0:0:Charlie &:/root:/bin/sh
|
||||
EOM
|
||||
|
||||
cat > /mnt/etc/master.passwd <<EOM
|
||||
root::0:0::0:0:Charlie &:/root:/bin/sh
|
||||
EOM
|
||||
|
||||
chmod 600 /mnt/etc/master.passwd
|
||||
chmod 644 /mnt/etc/passwd
|
||||
/usr/sbin/pwd_mkdb -d/mnt/etc /mnt/etc/master.passwd
|
||||
|
||||
#
|
||||
# umount the floppy and inform the user
|
||||
#
|
||||
/sbin/umount /mnt
|
||||
echo "The floppy has been unmounted and is now ready."]]>
|
||||
</programlisting>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>После сбоя</title>
|
||||
|
||||
<para>Главный вопрос: выжило ли ваше оборудование? Вы регулярно делали
|
||||
резервные копии, так что нет нужды беспокоиться о программном
|
||||
обеспечении.</para>
|
||||
|
||||
<para>Если оборудование было повреждено, первым делом замените
|
||||
неисправные компоненты.</para>
|
||||
|
||||
<para>Если с оборудованием все в порядке, проверьте ваши дискеты. При
|
||||
использовании самостоятельно созданной загрузочной дискеты,
|
||||
загрузитесь в однопользовательском режиме (набрав
|
||||
<literal>-s</literal> в приглашении <prompt>boot:</prompt>).
|
||||
Пропустите следующий абзац.</para>
|
||||
|
||||
<para>Если вы используете дискеты <filename>boot.flp</filename> и
|
||||
<filename>fixit.flp</filename>, читайте дальше. Вставьте дискету
|
||||
<filename>boot.flp</filename> в первый дисковод и загрузите
|
||||
компьютер. На экран будет выведено оригинальное меню установки.
|
||||
Выберите пункт <literal>Fixit--Repair mode with CDROM or
|
||||
floppy</literal>. После вывода приглашения вставьте
|
||||
<filename>fixit.flp</filename>. <command>restore</command> и другие
|
||||
нужные вам программы находятся в
|
||||
<filename>/mnt2/stand</filename>.</para>
|
||||
|
||||
<para>Восстановите по отдельности каждую файловую систему.</para>
|
||||
|
||||
<para>Попробуйте выполнить команду &man.mount.8; (например,
|
||||
<command>mount /dev/da0a /mnt</command>) по отношению к корневому
|
||||
разделу вашего первого диска. Если метка диска была испорчена,
|
||||
то воспользуйтесь командой &man.disklabel.8; для переразбиения на
|
||||
разделы и разметки диска так, чтобы получившаяся метка совпала с той,
|
||||
которая вами была распечатана и сохранена. Для повторного создания
|
||||
файловых систем используйте утилиту &man.newfs.8;. Повторно
|
||||
смонтируйте корневой раздел дискеты в режиме чтения-записи
|
||||
(<command>mount -u -o rw /mnt</command>). Воспользуйтесь вашей
|
||||
программой резервного копирования и резервными копиями на лентах для
|
||||
восстановления данных для этой файловой системы (например.
|
||||
<command>restore vrf /dev/sa0</command>). Размонтируйте файловую
|
||||
систему (например, <command>umount /mnt</command>). Повторите эту
|
||||
процедуру для каждой файловой системы, которая была запорчена.</para>
|
||||
|
||||
<para>Как только ваша система заработает, сделайте резервную копию на
|
||||
новые ленты. Что бы ни вызвало сбой или потерю данных, это может
|
||||
случиться снова. Еще один час, потраченный в этот момент, может
|
||||
спасти вас от неприятностей в будущем.</para>
|
||||
</sect3>
|
||||
|
||||
<![ %not.published; [
|
||||
|
||||
<sect3>
|
||||
<title>* Я не был готов к катастрофе, и что теперь?</title>
|
||||
|
||||
<para></para>
|
||||
</sect3>
|
||||
]]>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="backups-floppybackups">
|
||||
<title>Что насчет резервных копий на дискетах?</title>
|
||||
|
||||
<sect2 id="floppies-using">
|
||||
<title>Можно ли использовать дискеты для создания резервных копий моих
|
||||
данных?</title>
|
||||
|
||||
<para>На самом деле дискеты не подходят для создания резервных копий,
|
||||
потому что:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Носитель ненадежен, особенно если речь идет о больших сроках
|
||||
хранения</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Создание резервных копий и восстановление данных происходит
|
||||
очень медленно</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Дискеты имеют весьма ограниченную емкость (дни, когда весь
|
||||
винчестер копировался на десяток или около того дискет, давно
|
||||
прошли).</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Несмотря на все это, если у вас нет другого способа сделать
|
||||
резервную копию ваших данных, то дискеты все же лучше, чем
|
||||
ничего.</para>
|
||||
|
||||
<para>Если вы используете дискеты, то проверьте, что они должны быть
|
||||
хорошего качества. Дискеты, которые валялись по всему офису в течении
|
||||
нескольких лет, не подойдут. Идеально использовать новые от известного
|
||||
производителя.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="floppies-creating">
|
||||
<title>Итак, как же сделать резервную копию данных на дискетах?</title>
|
||||
|
||||
<para>Самым лучшим методом создания резервной копии на дискете является
|
||||
использование утилиты &man.tar.1; с опцией <option>-M</option>
|
||||
(многотомные архивы), которая позволяет размещать архивы на нескольких
|
||||
дискетах.</para>
|
||||
|
||||
<para>Для копирования всех файлов в текущем каталоге и подкаталогах
|
||||
выполните следующее (работая как пользователь root):</para>
|
||||
|
||||
<screen>
|
||||
&prompt.root; <userinput>tar Mcvf /dev/rfd0 *</userinput>
|
||||
</screen>
|
||||
|
||||
<para>Когда первая дискета окажется полностью заполненной, программа
|
||||
&man.tar.1; выдаст запрос на следующий том (так как работа утилиты
|
||||
&man.tar.1; не зависит от носителя, она имеет дело с томами. В этом
|
||||
смысле это означает дискету)</para>
|
||||
|
||||
<screen>
|
||||
Prepare volume #2 for /dev/rfd0 and hit return:
|
||||
</screen>
|
||||
|
||||
<para>Это сообщение будет повторяться (со все увеличивающимся номером
|
||||
тома) до тех пор, пока все указанные файлы не будут
|
||||
заархивированы.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="floppies-compress">
|
||||
<title>Можно ли резервные копии подвергнуть компрессии?</title>
|
||||
|
||||
<para>К сожалению, &man.tar.1; при создании многотомных архивов не
|
||||
позволяет использовать опцию <option>-z</option>. Вы конечно же,
|
||||
можете скомпрессировать все файлы утилитой &man.gzip.1;, программой
|
||||
&man.tar.1; скопировать их на дискеты, а затем распаковать файлы
|
||||
снова утилитой &man.gunzip.1;!</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="floppies-restoring">
|
||||
<title>Как восстановить данные из моих резервных копий?</title>
|
||||
|
||||
<para>Для полного восстановления архива воспользуйтесь такой
|
||||
командой:</para>
|
||||
|
||||
<screen>
|
||||
&prompt.root; <userinput>tar Mxvf /dev/rfd0</userinput>
|
||||
</screen>
|
||||
|
||||
<para>Для восстановления только конкретных файлов вы можете либо начать
|
||||
с первой дискеты и выдать такую команду:</para>
|
||||
|
||||
<screen>
|
||||
&prompt.root; <userinput>tar Mxvf /dev/rfd0 <replaceable>filename</replaceable></userinput>
|
||||
</screen>
|
||||
|
||||
<para>Программа &man.tar.1; будет выдавать запрос на подачу последующих
|
||||
дискет до тех пор, пока не найдет требуемый файл.</para>
|
||||
|
||||
<para>Как альтернатива, если вы знаете, на какой дискете расположен файл,
|
||||
то вы можете просто подать ее и дать ту же самую команду, что и выше.
|
||||
Заметьте, что если первый файл на дискете является продолжением
|
||||
предыдущего, то утилита &man.tar.1; выдаст предупреждение о том, что
|
||||
не может его восстановить, хотя вы этого и не просили делать!</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-declaration: "../chapter.decl"
|
||||
sgml-indent-data: t
|
||||
sgml-omittag: nil
|
||||
sgml-always-quote-attributes: t
|
||||
sgml-parent-document: ("../book.sgml" "part" "chapter")
|
||||
End:
|
||||
-->
|
||||
|
|
@ -1,682 +0,0 @@
|
|||
<!--
|
||||
The FreeBSD Russian Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDru: frdp/doc/ru_RU.KOI8-R/books/handbook/kerneldebug/chapter.sgml,v 1.2 2000/11/10 11:53:52 phantom Exp $
|
||||
|
||||
Original revision: 1.25
|
||||
-->
|
||||
|
||||
<chapter id="kerneldebug">
|
||||
<title>Отладка ядра</title>
|
||||
|
||||
<para><emphasis>Текст предоставили &a.paul; и &a.joerg;</emphasis></para>
|
||||
|
||||
<sect1>
|
||||
<title>Отладка аварийных образов ядра при помощи
|
||||
<command>kgdb</command></title>
|
||||
|
||||
<para>Вот некоторые указания по работе с отладкой ядра с аварийными
|
||||
образами памяти. При этом предполагается, что у вас достаточно места
|
||||
на разделе подкачки для аварийного образа памяти. Если у вас есть
|
||||
несколько разделов подкачки и первый слишком мал для размещения образа
|
||||
памяти, вы можете настроить ядро на использование другого устройства
|
||||
для сброса образа памяти (в строке <literal>config kernel</literal> или
|
||||
указать его при помощи команды &man.dumpon.8;. Лучше всего
|
||||
использовать &man.dumpon.8;, задав переменную
|
||||
<literal>dumpdev</literal> в файле <filename>/etc/rc.conf</filename>.
|
||||
Как правило, вам нужно будет задать одно из устройств подкачки,
|
||||
перечисленных в файле <filename>/etc/fstab</filename>. Сброс образов
|
||||
памяти на устройства, не являющиеся устройствами подкачки, напрмер,
|
||||
ленты, в данный момент не поддерживаются. Настройте ваше ядро при
|
||||
помощи команды <command>config -g</command>. Обратитесь к разделу
|
||||
<link linkend="kernelconfig">Настройка ядра</link> за более подробной
|
||||
информацией о настройке ядра FreeBSD.</para>
|
||||
|
||||
<para>Используйте команду &man.dumpon.8; для указания ядру места, куда
|
||||
нужно помещать образ памяти (отметьте, что это будут сделано после
|
||||
настройки соответствующего раздела как раздел подкачки через
|
||||
&man.swapon.8;). Обычно это делается через
|
||||
<filename>/etc/rc.conf</filename> и <filename>/etc/rc</filename>.
|
||||
Либо вы можете задать устройство для сброса образа памяти явно через
|
||||
параметр <literal>dump</literal> в строке <literal>config</literal>
|
||||
конфигурационного файла вашего ядра. Такой способ использовать не
|
||||
рекомендуется и он должен использоваться, только если вы хотите
|
||||
получать аварийные образы памяти ядра, которое аварийно завершает свою
|
||||
работу при загрузке.</para>
|
||||
|
||||
<note>
|
||||
<para>Далее термин <command>kgdb</command> означает утилиту
|
||||
<command>gdb</command>, которая запущена в <quote>режиме отладки
|
||||
ядра</quote>. Этот режим достигается либо при запуске
|
||||
<command>gdb</command> с параметром <option>-k</option>, либо
|
||||
компоновкой и запуском его под именем <command>kgdb</command>. По
|
||||
умолчанию этого, однако, не делается и эта идея, в общем-то, не
|
||||
поддерживается, потому что разработчикам GNU не нравится, когда их
|
||||
утилиты работают по-другому, будучи вызванными по другому имени. В
|
||||
будущих релизах такая возможность может исчезнуть.</para>
|
||||
</note>
|
||||
|
||||
<tip>
|
||||
<para>Если вы используете FreeBSD версии 3 или более раннюю, вы должны
|
||||
выполнить усечение отладочного ядра командой strip, а не
|
||||
устанавливать большое отладочное ядро:</para>
|
||||
|
||||
<screen>
|
||||
&prompt.root; <userinput>cp kernel kernel.debug</userinput>
|
||||
&prompt.root; <userinput>strip -g kernel</userinput>
|
||||
</screen>
|
||||
|
||||
<para>Этот шаг не так уж и необходим, но рекомендуем. (Во FreeBSD 4
|
||||
и более поздних релизах этот шаг выполняется автоматически в конце
|
||||
процесса построения ядра <command>make</command>.) Когда ядро
|
||||
усечено, автоматически или при помощи команд выше, вы можете
|
||||
установить его обычным образом, набрав <command>make
|
||||
install</command>.</para>
|
||||
|
||||
<para>Заметьте, что в старых версиях FreeBSD (до 3.1, не включая этот
|
||||
релиз), используется ядра в формате a.out, поэтому их таблицы
|
||||
символов должны располагаться постоянно в памяти. С большой таблицей
|
||||
символов в не усеченном отладочном ядре это излишняя трата. Последние
|
||||
релизы FreeBSD используют ядра в формате ELF, где это не является
|
||||
проблемой.</para>
|
||||
</tip>
|
||||
|
||||
<para>Если вы тестируете новое ядро, скажем, набирая имя нового ядра в
|
||||
приглашении загрузчика, но вам нужно загружать и работать с другим
|
||||
ядром, чтобы снова вернуться к нормальному функционированию, загружайте
|
||||
его только в однопользовательском режиме при помощи флага
|
||||
<option>-s</option>, указываемого при загрузке, а затем выполните такие
|
||||
шаги:</para>
|
||||
|
||||
<screen>
|
||||
&prompt.root; <userinput>fsck -p</userinput>
|
||||
&prompt.root; <userinput>mount -a -t ufs</userinput> # so your file system for /var/crash is writable
|
||||
&prompt.root; <userinput>savecore -N /kernel.panicked /var/crash</userinput>
|
||||
&prompt.root; <userinput>exit</userinput> # ...to multi-user
|
||||
</screen>
|
||||
|
||||
<para>Эта последовательность указывает программе &man.savecore.8; на
|
||||
использование другого ядра для извлечения символических имен. Иначе
|
||||
она будет использовать ядро, работающее в данный момент и, скорее
|
||||
всего, ничего не сделает, потому что аварийный образ памяти и символы
|
||||
ядра будут отличаться.</para>
|
||||
|
||||
<para>А теперь, после сброса аварийного дампа, перейдите в каталог
|
||||
<filename>/sys/compile/WHATEVER</filename> и запустите команду
|
||||
<command>kgdb</command>. Из программы <command>kgdb</command> сделайте
|
||||
вот что:
|
||||
|
||||
<screen>
|
||||
<userinput>symbol-file kernel.debug</userinput>
|
||||
<userinput>exec-file /var/crash/kernel.0</userinput>
|
||||
<userinput>core-file /var/crash/vmcore.0</userinput>
|
||||
</screen>
|
||||
|
||||
и вуаля - вы можете отлаживать аварийный дамп, используя исходные
|
||||
тексты ядра точно также, как вы это делаете с любой другой
|
||||
программой.</para>
|
||||
|
||||
<para>Вот журнал команд сеанса работы <command>kgdb</command>,
|
||||
иллюстрирующий эту процедуру. Длинные строки были разорваны для
|
||||
улучшения читабельности и для удобства строки были пронумерованы.
|
||||
Все остальное является трассировкой ошибки, реально возникнувшей во
|
||||
время работы над драйвером консоли pcvt.</para>
|
||||
|
||||
<screen>
|
||||
1:Script started on Fri Dec 30 23:15:22 1994
|
||||
2:&prompt.root; <userinput>cd /sys/compile/URIAH</userinput>
|
||||
3:&prompt.root; <userinput>kgdb kernel /var/crash/vmcore.1</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>where</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>up 10</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>frame frame->tf_ebp frame->tf_eip</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>list</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>print tp</userinput>
|
||||
53:Reading in symbols for ../../i386/i386/cons.c...done.
|
||||
54:$1 = (struct tty *) 0x1bae
|
||||
55:<prompt>(kgdb)</prompt> <userinput>print tp->t_line</userinput>
|
||||
56:$2 = 1767990816
|
||||
57:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
62:#2 0xf0132c34 in spec_open ()
|
||||
63:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
64:#3 0xf012d014 in vn_open ()
|
||||
65:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
66:#4 0xf012a183 in open ()
|
||||
67:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
75:Initial frame selected; you cannot go up.
|
||||
76:<prompt>(kgdb)</prompt> <userinput>quit</userinput>
|
||||
77:&prompt.root; <userinput>exit</userinput>
|
||||
78:exit
|
||||
79:
|
||||
80:Script done on Fri Dec 30 23:18:04 1994
|
||||
</screen>
|
||||
|
||||
<para>Комментарии к вышеприведенному журналу:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>строка 6:</term>
|
||||
|
||||
<listitem>
|
||||
<para>Это дамп, взятый при помощи DDB (смотри ниже), поэтому
|
||||
комментарий к аварийному останову имеет именно вид <quote>because
|
||||
you said to!</quote> и трассировка стека глубока; однако
|
||||
изначальной причиной перехода в DDB была аварийная остановка при
|
||||
возникновению ошибки страницы памяти.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>строка 20:</term>
|
||||
|
||||
<listitem>
|
||||
<para>Это местонахождение функции <function>trap()</function> в
|
||||
трассировке стека.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>строка 36:</term>
|
||||
|
||||
<listitem>
|
||||
<para>Принудительное использование новой границы стека; теперь это
|
||||
не нужно. Теперь предполагается, что границы стека указывают на
|
||||
правое расположение, даже в случае аварийного останова. (У меня
|
||||
нет под рукой новый аварийный дамп <g>, с моим ядром
|
||||
аварийная ситуация не случалась давно.) Глядя на строку
|
||||
исходного кода 403, можно сказать, что весьма вероятно, что либо
|
||||
виноват доступ по указателю <quote>tp</quote>, либо был выход за
|
||||
границы массива.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>строка 52:</term>
|
||||
|
||||
<listitem>
|
||||
<para>Похоже, что виноват указатель, но он является допустимым
|
||||
адресом.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>строка 56:</term>
|
||||
|
||||
<listitem>
|
||||
<para>Однако, очевидно, что он указывает на мусор, так что мы нашли
|
||||
нашу ошибку! (Для тех, кто не знаком с этой частью кода:
|
||||
<literal>tp->t_line</literal> служит для хранения режима
|
||||
канала консольного устройства, и это должно быть достаточно
|
||||
маленькое целое число.)</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Отладка аварийного дампа с помощью DDD</title>
|
||||
|
||||
<para>Возможно также и исследование аварийного дампа ядра при помощи
|
||||
такого графического отладчика, как <command>ddd</command>. Добавьте
|
||||
флаг <option>-k</option> к командной строке <command>ddd</command>,
|
||||
которую вы обычно используете для его вызова. Например;</para>
|
||||
|
||||
<screen>
|
||||
&prompt.root; <userinput>ddd -k /var/crash/kernel.0 /var/crash/vmcore.0</userinput>
|
||||
</screen>
|
||||
|
||||
<para>После этого у вас должно получиться исследование аварийного дампа
|
||||
при помощи графического интерфейса <command>ddd</command>.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Посмертный анализ дампа</title>
|
||||
|
||||
<para>Что делать, если ядро аварийно завершает работу, хотя этого вы не
|
||||
хотели и поэтому командой <command>config -g</command> его не
|
||||
компилировали? Здесь не все еще потеряно. Не паникуйте!</para>
|
||||
|
||||
<para>Конечно, вам нужно включить создание аварийных дампов. Смотрите
|
||||
выше, что вы должны для этого сделать.</para>
|
||||
|
||||
<para>Перейдите в каталог конфигурации ядра
|
||||
(<filename>/usr/src/sys/<replaceable>arch</replaceable>/conf</filename>)
|
||||
и отредактируйте ваш конфигурационный файл. Раскомментируйте (или
|
||||
добавьте, если она не существует) такую строку</para>
|
||||
|
||||
<programlisting>
|
||||
makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols
|
||||
</programlisting>
|
||||
|
||||
<para>Перестройте ядро. Из-за изменения метки времени в Makefile будут
|
||||
перестроены некоторые другие объектные файлы, например,
|
||||
<filename>trap.o</filename>. К некоторому счастью, добавление опции
|
||||
<option>-g</option> не изменит все и вся в генерируемом коде, так что
|
||||
в конце концов вы получите новое ядро с тем же кодом, что и сбоящее
|
||||
ядро, за исключением наличия отладочной информации. По крайней мере,
|
||||
вы можете сравнить старый и новый размеры ядер командой &man.size.1;.
|
||||
Если они не совпадают, то вам придется отказаться от вашей
|
||||
затеи.</para>
|
||||
|
||||
<para>Исследуйте дамп так, как это описано выше. Отладочной информации
|
||||
может не хватать в некоторых местах, как это можно видеть в трассировке
|
||||
стека примера выше, когда некоторые функции выводятся без номеров строк
|
||||
и списка аргументов. Если вам нужно больше отладочной информации,
|
||||
удалите соответствующие объектные файлы и повторите сеанс работы с
|
||||
<command>kgdb</command>, пока не получите достаточно подробную
|
||||
информацию.</para>
|
||||
|
||||
<para>Не гарантируется, что все это будет работать, однако в большинстве
|
||||
случаев все работает прекрасно.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Отладка ядра в режиме реального времени с помощью DDB</title>
|
||||
|
||||
<para>Хотя <command>kgdb</command> является отладчиком не реального
|
||||
времени с высокоуровневым пользовательским интерфейсом, есть несколько
|
||||
вещей, которые он сделать не сможет. Самыми важными из них являются
|
||||
точки останова и пошаговое выполнение кода ядра.</para>
|
||||
|
||||
<para>Если вам нужно выполнять низкоуровневую отладку вашего ядра, то на
|
||||
этот случай имеется отладчик реального времени, который называется DDB.
|
||||
Он позволяет устанавливать точки останова, выполнять функции ядра по
|
||||
шагам, исследовать и изменять переменные ядра и прочее. Однако он не
|
||||
может использовать исходные тексты ядра и имеет доступ только к
|
||||
глобальным и статическим символам, а не ко всей отладочной информации,
|
||||
как <command>kgdb</command>.</para>
|
||||
|
||||
<para>Чтобы отконфигурировать ваше ядро для включения DDB, добавьте
|
||||
строчку с параметром
|
||||
|
||||
<programlisting>
|
||||
options DDB
|
||||
</programlisting>
|
||||
|
||||
в ваш конфигурационный файл, и перестройте ядро. (Обратитесь к разделу
|
||||
о <link linkend="kernelconfig">конфигурации ядра</link> для выяснения
|
||||
деталей конфигурации ядра FreeBSD.</para>
|
||||
|
||||
<note>
|
||||
<para>Заметьте, что, если у вас устаревшая версия загрузочных блоков,
|
||||
то отладочная информация может оказаться не загруженной. Обновите
|
||||
блоки загрузки; самые новые загружают символы для DDB
|
||||
автоматически.)</para>
|
||||
</note>
|
||||
|
||||
<para>После того, как ядро с DDB запущено, есть несколько способов войти
|
||||
в DDB. Первый, и самый простой, способ заключается в наборе флага
|
||||
загрузки <option>-d</option> прямо в приглашении загрузчика. Ядро
|
||||
будет запущено в режиме отладки и войдет в DDB до выполнения процедуры
|
||||
распознавания каких бы то ни было устройств. Поэтому вы можете
|
||||
выполнить отладку даже функций распознавания/присоединения
|
||||
устройств.</para>
|
||||
|
||||
<para>Второй способ - это особая комбинация клавиш на клавиатуре, как
|
||||
правило, Ctrl-Alt-ESC. Для системной консоли syscon это может быть
|
||||
переопределено; некоторые из поставляемых раскладок это выполняют, так
|
||||
что присмотритесь. Для последовательных консолей имеется параметр,
|
||||
позволяющий использовать последовательность BREAK на канале консоли для
|
||||
входа в DDB (<literal>options BREAK_TO_DEBUGGER</literal> в
|
||||
конфигурационном файле ядра). По умолчанию этого не делается, так как
|
||||
существует множество паршивых последовательных адаптеров, которые
|
||||
генерируют последовательность BREAK, к примеру, при вытягивании
|
||||
кабеля.</para>
|
||||
|
||||
<para>Третий способ заключается во входе в DDB при возникновении
|
||||
любой аварийной ситуации, если ядро его использует. По этой причине
|
||||
не очень умно конфигурировать ядро с DDB для машины, которая работает
|
||||
без присмотра.</para>
|
||||
|
||||
<para>Команды DDB примерно повторяют некоторые команды
|
||||
<command>gdb</command>. Первым делом вам, наверное, нужно задать точку
|
||||
останова:</para>
|
||||
|
||||
<screen>
|
||||
<userinput>b function-name</userinput>
|
||||
<userinput>b address</userinput>
|
||||
</screen>
|
||||
|
||||
<para>Значения по умолчанию воспринимаются в шестнадцатиричном виде, но
|
||||
чтобы отличать их от имен символов; шестнадцатиричные числа,
|
||||
начинающиеся с букв <literal>a-f</literal>, должны предваряться
|
||||
символами <literal>0x</literal> (это опционально для других чисел).
|
||||
Разрешены простые выражения, например:
|
||||
<literal>function-name + 0x103</literal>.</para>
|
||||
|
||||
<para>Чтобы продолжить работу прерванного ядра, просто наберите:</para>
|
||||
|
||||
<screen><userinput>c</userinput></screen>
|
||||
|
||||
<para>Чтобы получить трассировку стека, задайте:</para>
|
||||
|
||||
<screen><userinput>trace</userinput></screen>
|
||||
|
||||
<note>
|
||||
<para>Заметьте, что при входе в DDB по специальной комбинации, ядро
|
||||
в данный момент обслуживает прерывание, так что трассировка стека
|
||||
может не дать много информации.</para>
|
||||
</note>
|
||||
|
||||
<para>Если вы хотите убрать точку останова, введите</para>
|
||||
|
||||
<screen>
|
||||
<userinput>del</userinput>
|
||||
<userinput>del address-expression</userinput>
|
||||
</screen>
|
||||
|
||||
<para>В первом варианте команда будет исполнена сразу же по достижении
|
||||
точки останова, а текущая точка останова будет удалена. Во второй
|
||||
форме можно удалить любую точку останова, однако вам нужно будет
|
||||
указать ее точный адрес; его можно получить из:</para>
|
||||
|
||||
<screen><userinput>show b</userinput></screen>
|
||||
|
||||
<para>Чтобы выполнить один шаг ядра, попробуйте:</para>
|
||||
|
||||
<screen><userinput>s</userinput></screen>
|
||||
|
||||
<para>При этом будет осуществляться пошаговое выполнение функций, однако
|
||||
вы можете трассировать их с помощью DDB, пока не будет достигнуто
|
||||
соответствие возвращаемому значению:</para>
|
||||
|
||||
<screen><userinput>n</userinput></screen>
|
||||
|
||||
<note>
|
||||
<para>Это отличается от команды <command>next</command> отладчика
|
||||
<command>gdb</command>; это похоже на команду <command>gdb</command>
|
||||
<command>finish</command>.</para>
|
||||
</note>
|
||||
|
||||
<para>Чтобы выводить значения в памяти, используйте, (к примеру):
|
||||
|
||||
<screen>
|
||||
<userinput>x/wx 0xf0133fe0,40</userinput>
|
||||
<userinput>x/hd db_symtab_space</userinput>
|
||||
<userinput>x/bc termbuf,10</userinput>
|
||||
<userinput>x/s stringbuf</userinput>
|
||||
</screen>
|
||||
|
||||
для доступа к данным типа слово/полуслово/байт и вывода в
|
||||
шестнадцатиричном/десятичном/символьном виде. Число после запятой
|
||||
означает счетчик объектов. Чтобы вывести следующие 0x10 объектов,
|
||||
просто укажите:</para>
|
||||
|
||||
<screen><userinput>x ,10</userinput></screen>
|
||||
|
||||
<para>Подобным же образом используйте
|
||||
|
||||
<screen><userinput>x/ia foofunc,10</userinput></screen>
|
||||
|
||||
для дизассемблирования и вывода первых 0x10 инструкций функции
|
||||
<function>foofunc</function> вместе с их адресом относительно
|
||||
начала <function>foofunc</function>.</para>
|
||||
|
||||
<para>Чтобы изменить значения в памяти, используйте команду write:</para>
|
||||
|
||||
<screen>
|
||||
<userinput>w/b termbuf 0xa 0xb 0</userinput>
|
||||
<userinput>w/w 0xf0010030 0 0</userinput>
|
||||
</screen>
|
||||
|
||||
<para>Модификатор команды
|
||||
(<literal>b</literal>/<literal>h</literal>/<literal>w</literal>)
|
||||
указывает на размер записываемых данных, первое следующее за ним
|
||||
выражение является адресом для записи, а оставшаяся часть
|
||||
интерпретируется как данные для записи в доступные области
|
||||
памяти.</para>
|
||||
|
||||
<para>Если вам нужно узнать текущее содержимое регистров,
|
||||
используйте:</para>
|
||||
|
||||
<screen><userinput>show reg</userinput></screen>
|
||||
|
||||
<para>Альтернативно вы можете вывести содержимое одного регистра по
|
||||
команде, скажем,
|
||||
|
||||
<screen><userinput>p $eax</userinput></screen>
|
||||
|
||||
и изменить его по:</para>
|
||||
|
||||
<screen><userinput>set $eax new-value</userinput></screen>
|
||||
|
||||
<para>Если вам нужно вызвать некоторую функцию ядра из DDB, просто
|
||||
укажите:</para>
|
||||
|
||||
<screen><userinput>call func(arg1, arg2, ...)</userinput></screen>
|
||||
|
||||
<para>Будет выведено возвращаемое значение.</para>
|
||||
|
||||
<para>Для вывода суммарной статистики по всем работающим процессам в
|
||||
стиле команды &man.ps.1; воспользуйтесь такой командой:</para>
|
||||
|
||||
<screen><userinput>ps</userinput></screen>
|
||||
|
||||
<para>Теперь вы узнали, почему ядро работает с ошибками и хотите
|
||||
выполнить перезагрузку. Запомните, что в зависимости от влияния
|
||||
предыдущих ошибок, не все части ядра могут работать так, как ожидается.
|
||||
Выполните одно из следующих действий для закрытия и перезагрузки вашей
|
||||
системы:</para>
|
||||
|
||||
<screen><userinput>panic</userinput></screen>
|
||||
|
||||
<para>Это приведет к созданию дампа ядра и перезагрузке, так что позже
|
||||
вы можете проанализировать дамп на более высоком уровне при помощи
|
||||
kgdb. Как правило, эта команда должна следовать за другой командой
|
||||
<command>continue</command>.</para>
|
||||
|
||||
<screen><userinput>call boot(0)</userinput></screen>
|
||||
|
||||
<para>Это может оказаться хорошим способом для корректного закрытия
|
||||
работающей системы, <function>sync()</function> для всех дисков и
|
||||
напоследок перезагрузка. Пока интерфейсы диска и файловой системы
|
||||
в ядре не повреждены, это может быть самым правильным способом закрытия
|
||||
системы.</para>
|
||||
|
||||
<screen><userinput>call cpu_reset()</userinput></screen>
|
||||
|
||||
<para>самый последнее средство при аварии и практически то же самое, что
|
||||
нажатие Большой Красной Кнопки.</para>
|
||||
|
||||
<para>Если вам нужен краткий справочник по командам, просто
|
||||
наберите:</para>
|
||||
|
||||
<screen><userinput>help</userinput></screen>
|
||||
|
||||
<para>Однако настоятельно рекомендуем отпечатать копию страницы
|
||||
справочника по &man.ddb.4; при подготовке к сеансу отладки. Помните,
|
||||
что трудно читать онлайновое руководство при пошаговом выполнении
|
||||
ядра.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Отладка ядра в режиме реального времени при помощи удаленного
|
||||
GDB</title>
|
||||
|
||||
<para>Эта возможность поддерживается во FreeBSD начиная с версии 2.2,
|
||||
и она на самом деле очень удобна.</para>
|
||||
|
||||
<para>В GDB уже давно имеется поддержка <emphasis>удаленной
|
||||
отладки</emphasis>. Это делается при помощи весьма простого протокола
|
||||
по последовательному каналу. В отличие от других методов, описанных
|
||||
выше, для этого вам требуется наличие двух машин. Одна из них является
|
||||
хостом, предоставляющим ресурсы для отладки, включая все исходные
|
||||
тексты и копию ядра со всеми символами в нем, а другая является целевой
|
||||
машиной, на которой запущена та же копия того же ядра (но без
|
||||
отладочной информации).</para>
|
||||
|
||||
<para>Вы должны настроить исследуемое ядро при помощи команды
|
||||
<command>config -g</command>, включить <option>DDB</option> в
|
||||
конфигурацию и откомпилировать его обычным образом. Это даст большой
|
||||
объем получаемого бинарного файла из-за отладочной информации.
|
||||
Скопируйте это ядро на целевую машину, усеките отладочную информацию
|
||||
командой <command>strip -x</command> и загрузите это ядро с
|
||||
использованием параметра загрузки <option>-d</option>. Подключите
|
||||
последовательный канал целевой машины, имеющий установленные флаги
|
||||
"flags 080" на соответствующем устройстве sio к любому
|
||||
последовательному каналу отладочного хоста. А теперь на отладочной
|
||||
машине перейдите в каталог компиляции целевого ядра и запустите
|
||||
gdb:</para>
|
||||
|
||||
<screen>
|
||||
&prompt.user; <userinput>gdb -k kernel</userinput>
|
||||
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...
|
||||
<prompt>(kgdb)</prompt>
|
||||
</screen>
|
||||
|
||||
<para>Проинициализируйте сеанс удаленной отладки (предполагается, что
|
||||
используется первый последовательный порт) такой командой:</para>
|
||||
|
||||
<screen>
|
||||
<prompt>(kgdb)</prompt> <userinput>target remote /dev/cuaa0</userinput>
|
||||
</screen>
|
||||
|
||||
<para>Теперь на целевом хосте (тот, который перешел в DDB даже до
|
||||
начала процесса обнаружения устройств) наберите:</para>
|
||||
|
||||
<screen>
|
||||
Debugger("Boot flags requested debugger")
|
||||
Stopped at Debugger+0x35: movb $0, edata+0x51bc
|
||||
<prompt>db></prompt> <userinput>gdb</userinput>
|
||||
</screen>
|
||||
|
||||
<para>DDB ответит следующим:</para>
|
||||
|
||||
<screen>Next trap will enter GDB remote protocol mode</screen>
|
||||
|
||||
<para>Каждый раз, когда вы будете набирать <command>gdb</command>, режим
|
||||
будет меняться между удаленным GDB и локальным DDB. Чтобы немедленно
|
||||
вызвать следующее прерывание, просто наберите <command>s</command>
|
||||
(step). Ваш хостирующий GDB получит управление над целевым
|
||||
ядром:</para>
|
||||
|
||||
<screen>
|
||||
Remote debugging using /dev/cuaa0
|
||||
Debugger (msg=0xf01b0383 "Boot flags requested debugger")
|
||||
at ../../i386/i386/db_interface.c:257
|
||||
<prompt>(kgdb)</prompt>
|
||||
</screen>
|
||||
|
||||
<para>Вы можете работать в этом сеансе точно также, как и в любом другом
|
||||
сеансе GDB, включая полный доступ к исходным текстам, запуск его в
|
||||
режиме gud-mode внутри окна Emacs (что дает вам автоматический вывод
|
||||
исходного кода в другом окне Emacs) и тому подобное.</para>
|
||||
|
||||
<para>Удаленный GDB также может использоваться для отладки модулей LKM.
|
||||
Сначала откомпилируйте LKM с отладочной информацией:</para>
|
||||
|
||||
<screen>
|
||||
&prompt.root; <userinput>cd /usr/src/lkm/linux</userinput>
|
||||
&prompt.root; <userinput>make clean; make COPTS=-g</userinput>
|
||||
</screen>
|
||||
|
||||
<para>Затем установите эту версию модуля на целевой машине, загрузите его
|
||||
и воспользуйтесь командой <command>modstat</command> для определения
|
||||
того, куда он был загружен:</para>
|
||||
|
||||
<screen>
|
||||
&prompt.root; <userinput>linux</userinput>
|
||||
&prompt.root; <userinput>modstat</userinput>
|
||||
Type Id Off Loadaddr Size Info Rev Module Name
|
||||
EXEC 0 4 f5109000 001c f510f010 1 linux_mod
|
||||
</screen>
|
||||
|
||||
<para>Возьмите адрес загрузки модуля и добавьте к нему 0x20 (для размера
|
||||
заголовка a.out). Получится адрес, куда был перемещен код модуля.
|
||||
Воспользуйтесь командой <command>add-symbol-file</command> в GDB для
|
||||
указания отладчику на модуль:</para>
|
||||
|
||||
<screen>
|
||||
<prompt>(kgdb)</prompt> <userinput>add-symbol-file /usr/src/lkm/linux/linux_mod.o 0xf5109020</userinput>
|
||||
add symbol table from file "/usr/src/lkm/linux/linux_mod.o" at
|
||||
text_addr = 0xf5109020? (y or n) <userinput>y</userinput>
|
||||
<prompt>(kgdb)</prompt>
|
||||
</screen>
|
||||
|
||||
<para>Теперь вы имеете доступ ко всем символам в LKM.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Отладка драйвера консоли</title>
|
||||
|
||||
<para>Так как для работы DDB вам требуется драйвер консоли, то в случае
|
||||
неисправностей самого драйвера консоли все становится гораздо сложнее.
|
||||
Вы можете вспомнить об использовании последовательной консоли (либо с
|
||||
исправленными загрузочными блоками, либо при указании флага
|
||||
<option>-h</option> в приглашении <prompt>Boot:</prompt>) и подключить
|
||||
обычный терминал к первому последовательному порту. DDB работает с
|
||||
любым отконфигурированным драйвером консоли, в том числе, конечно же,
|
||||
и с последовательной консолью.</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-declaration: "../chapter.decl"
|
||||
sgml-indent-data: t
|
||||
sgml-omittag: nil
|
||||
sgml-always-quote-attributes: t
|
||||
sgml-parent-document: ("../book.sgml" "part" "chapter")
|
||||
End:
|
||||
-->
|
||||
|
|
@ -1,177 +0,0 @@
|
|||
<!--
|
||||
The FreeBSD Russian Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/books/handbook/kernelopts/chapter.sgml,v 1.16 2000/06/14 00:47:36 jim Exp $
|
||||
$FreeBSDru: frdp/doc/ru_RU.KOI8-R/books/handbook/kernelopts/chapter.sgml,v 1.2 2000/11/10 11:55:24 phantom Exp $
|
||||
-->
|
||||
|
||||
<chapter id="kernelopts">
|
||||
<title>Добавление новых параметров конфигурации ядра</title>
|
||||
|
||||
<para><emphasis>Предоставил &a.joerg;</emphasis></para>
|
||||
|
||||
<note>
|
||||
<para>Перед тем, как читать этот раздел, вы должны усвоить материал
|
||||
раздела о <link linkend="kernelconfig">конфигурации ядра</link>.</para>
|
||||
</note>
|
||||
|
||||
<sect1>
|
||||
<title>Что же такое <emphasis>параметр ядра</emphasis>, в конце
|
||||
концов?</title>
|
||||
|
||||
<para>Использование параметров ядра в основном описано в разделе о <link
|
||||
linkend="kernelconfig-options">конфигурации ядра</link>. Там же
|
||||
имеется описание <quote>устаревших</quote> и параметров <quote>в новом
|
||||
стиле</quote>. Конечной целью является постепенный перевод всех
|
||||
поддерживаемых параметров ядра к новому стилю, так чтобы для тех, кто
|
||||
корректно выполняют команду <command>make depend</command> в каталоге
|
||||
компиляции ядра после запуска &man.config.8;, процесс построения
|
||||
автоматически принимал модифицированные параметры и
|
||||
перекомпилировал только те файлы, которые необходимы. Удаление старого
|
||||
каталога компиляции при каждом перезапуске &man.config.8;, как это
|
||||
еще происходит сейчас, затем может быть убрано.</para>
|
||||
|
||||
<para>В своей основе параметр ядра является не более чем определение
|
||||
макроса препроцессора C для процесса компиляции ядра. Чтобы сделать
|
||||
построение полностью настраиваемым через опции процессом,
|
||||
соответствующая часть исходных текстов ядра (или файла
|
||||
<filename>.h</filename> ядра) должна быть написана с упором на
|
||||
концепцию параметров, то есть чтобы значения, используемые по
|
||||
умолчанию, могли быть переопределены параметрами конфигурации. Это
|
||||
обычно делается примерно так:</para>
|
||||
|
||||
<programlisting>
|
||||
#ifndef THIS_OPTION
|
||||
#define THIS_OPTION (некоторое значение по умолчанию)
|
||||
#endif /* THIS_OPTION */
|
||||
</programlisting>
|
||||
|
||||
<para>Этим способом администратор, задающий другое значение для параметра
|
||||
в своем конфигурационном файле, избегает использования значения по
|
||||
умолчанию и заменяет его новым значением. Более того, новое значение
|
||||
будет подставлено в исходный код во время работы препроцессора, так что
|
||||
это должно быть правильное выражение языка C в контексте использования
|
||||
значения по умолчанию.</para>
|
||||
|
||||
<para>Также возможно создание параметров, которые не принимают
|
||||
определенного значения, а просто включают или выключают некоторую часть
|
||||
кода, обрамляя его в</para>
|
||||
|
||||
<programlisting>
|
||||
#ifdef THAT_OPTION
|
||||
|
||||
[здесь ваш код]
|
||||
|
||||
#endif
|
||||
</programlisting>
|
||||
|
||||
<para>Простое упоминание <literal>THAT_OPTION</literal> в
|
||||
конфигурационном файле (со значением или без него) приведет к включению
|
||||
соответствующего кода.</para>
|
||||
|
||||
<para>Те, кто знаком с языком C, могут сказать, что все может считаться
|
||||
как <quote>config option</quote>, там где есть по крайней мере одна
|
||||
строчка <literal>#ifdef</literal>... Однако вряд ли многие будут
|
||||
писать</para>
|
||||
|
||||
<programlisting>
|
||||
options notyet,notdef
|
||||
</programlisting>
|
||||
|
||||
<para>в своих конфигурационных файлах и потом удивляться, почему
|
||||
компиляция ядра не проходит. <!-- smiley -->:-)</para>
|
||||
|
||||
<para>Более точно, использование уникальных имен для параметров делает
|
||||
очень трудным отслеживание их использования в дереве исходных текстов
|
||||
ядра. В использовании схемы параметров в <emphasis>новом
|
||||
стиле</emphasis> имеется рациональное зерно, когда каждый параметр
|
||||
помещается в отдельный файл <filename>.h</filename> в каталоге
|
||||
компиляции ядра, который по соглашению называется
|
||||
<filename>opt_<replaceable>foo</replaceable>.h</filename>. Таким
|
||||
образом, могут быть применены обычные зависимости в Makefile, и утилита
|
||||
<command>make</command> может определить, что нужно перекомпилировать
|
||||
при изменении определенного параметра.</para>
|
||||
|
||||
<para>Параметры при использовании механизма в старом стиле имеют одно
|
||||
преимущество для локальных изменений или для экспериментальных
|
||||
параметров, которые имеют короткий срок жизни: так как весьма легко
|
||||
добавить новую строку <literal>#ifdef</literal> к исходному коду ядра,
|
||||
то это уже превращается в параметр конфигурации ядра. В таком случае
|
||||
администратор, использующий параметры таким образом, несет
|
||||
ответственность за знание влияния этого параметра (и может быть, за
|
||||
принудительную перекомпиляцию вручную частей ядра). Как только перевод
|
||||
всех поддерживаемых опций будет сделан, программа &man.config.8; будет
|
||||
выдавать предупреждение о не поддерживаемой опции, появившейся в
|
||||
конфигурационном файле, однако она будет включать ее в файл Makefile
|
||||
ядра.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>И что я должен для этого сделать?</title>
|
||||
|
||||
<para>Во-первых, отредактируйте файл
|
||||
<filename>sys/conf/options</filename> (или
|
||||
<filename>sys/<replaceable><arch></replaceable>/conf/options.<replaceable><arch></replaceable></filename>,
|
||||
например <filename>sys/i386/conf/options.i386</filename>), и выберите
|
||||
файл <filename>opt_<replaceable>foo</replaceable>.h</filename>,
|
||||
в котором лучше всего поместить вашу новую опцию.</para>
|
||||
|
||||
<para>Если имеется что-то, уже похожее на предназначение новой опции,
|
||||
выберите это. Например, опции, изменяющие общее поведение подсистемы
|
||||
SCSI, могут быть помещены в
|
||||
<filename>opt_scsi.h</filename>. По умолчанию простое упоминание опции
|
||||
в соответствующем файле опций, скажем, <literal>FOO</literal>, приводит
|
||||
к тому, что ее значение помещается в соответствующий файл
|
||||
<filename>opt_foo.h</filename>. Это может быть переопределено в
|
||||
правой части правила указанием другого имени файла.</para>
|
||||
|
||||
<para>Если файла
|
||||
<filename>opt_<replaceable>foo</replaceable>.h</filename> для
|
||||
предполагаемой новой опции еще нет, придумайте новое имя. Сделайте его
|
||||
значимым и прокомментируйте новый раздел в файле
|
||||
<filename>options[<replaceable>.<arch></replaceable>]</filename>.
|
||||
Утилита &man.config.8; автоматически воспримет изменения и создаст
|
||||
этот файл при следующем своем запуске. Большинство опций должно
|
||||
оказаться в заголовочном файле..</para>
|
||||
|
||||
<para>Размещение слишком большого количества опций в одном файле
|
||||
<filename>opt_<replaceable>foo</replaceable>.h</filename> приведет к
|
||||
перестроению слишком большого количества файлов ядра при изменении
|
||||
одной из опций в конфигурационном файле.</para>
|
||||
|
||||
<para>Наконец, определите, какие файлы ядра зависят от новой опции. Если
|
||||
только вы не только что придумали вашу опцию и она еще нигде не
|
||||
упоминается, то команда
|
||||
<screen>
|
||||
&prompt.user; <userinput>find /usr/src/sys -type f | xargs fgrep NEW_OPTION</userinput>
|
||||
</screen>
|
||||
вам поможет ее найти. Сделайте это и отредактируйте все эти файлы, а
|
||||
также добавьте <programlisting>#include "opt_foo.h"</programlisting>
|
||||
<emphasis>вверху</emphasis> до всех строк
|
||||
<literal>#include <xxx.h></literal>. Эта последовательность
|
||||
очень важна, так как опции могут переопределять значения по умолчанию
|
||||
из обычных включаемых файлов, если эти значения по умолчанию даются в
|
||||
форме <programlisting> #ifndef NEW_OPTION #define NEW_OPTION (что-то)
|
||||
#endif</programlisting> в обычном заголовке.</para>
|
||||
|
||||
<para>Добавление опции, которая переопределяет что-то в системном
|
||||
заголовочном файле (то есть файле, находящемся в каталоге
|
||||
<filename>/usr/include/sys/</filename>), практически всегда ошибочно.
|
||||
<filename>opt_<replaceable>foo</replaceable>.h</filename> не может быть
|
||||
включен в те файлы, потому что это изменит заголовки более серьезно,
|
||||
но если он не включен, то в местах его включения может получиться
|
||||
рассогласованность значений для этой опции. Да, такие прецеденты имеют
|
||||
место и сейчас, но это их не оправдывает.</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-declaration: "../chapter.decl"
|
||||
sgml-indent-data: t
|
||||
sgml-omittag: nil
|
||||
sgml-always-quote-attributes: t
|
||||
sgml-parent-document: ("../book.sgml" "part" "chapter")
|
||||
End:
|
||||
-->
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
<!--
|
||||
îÁÚ×ÁÎÉÑ ÇÒÕÐÐ ÎÏ×ÏÓÔÅÊ ÐÏÓ×ÑÝÅÎÎÙÈ FreeBSD
|
||||
|
||||
The FreeBSD Russian Documentation Project
|
||||
$FreeBSD$
|
||||
$FreeBSDru: frdp/doc/ru_RU.KOI8-R/books/handbook/newsgroups.ent,v 1.2 2000/07/08 13:35:13 phantom Exp $
|
||||
Original revision: 1.2
|
||||
-->
|
||||
|
||||
<!ENTITY ng.misc "ÇÒÕÐÐÁ ÎÏ×ÏÓÔÅÊ
|
||||
<ulink url='news:comp.unix.bsd.freebsd.misc'>comp.unix.bsd.freebsd.misc</ulink>">
|
||||
|
|
@ -1,431 +0,0 @@
|
|||
<!--
|
||||
The FreeBSD Russian Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDru: frdp/doc/ru_RU.KOI8-R/books/handbook/policies/chapter.sgml,v 1.1 2000/11/12 13:32:19 andy Exp $
|
||||
|
||||
Original revision: 1.18
|
||||
-->
|
||||
|
||||
<chapter id="policies">
|
||||
<title>Рекомендации и требования к исходному коду</title>
|
||||
|
||||
<para><emphasis>Текст предоставил &a.phk;.</emphasis></para>
|
||||
|
||||
<para>В этой главе описываются различные рекомендации и требования, которые
|
||||
должны соблюдаться в дереве исходных текстов FreeBSD.</para>
|
||||
|
||||
<sect1 id="policies-maintainer">
|
||||
<title><makevar>MAINTAINER</makevar> в make-файлах</title>
|
||||
|
||||
<para>Июнь 1996.</para>
|
||||
|
||||
<para>Если некоторая часть дистрибутива FreeBSD поддерживается некоторым
|
||||
человеком или группой людей, они могут сообщить об этом миру, добавив
|
||||
строчку
|
||||
|
||||
<programlisting>
|
||||
MAINTAINER= email-addresses</programlisting>
|
||||
|
||||
в файл <filename>Makefile</filename>, соответствующий этой части
|
||||
исходного кода.</para>
|
||||
|
||||
<para>Смысл этого в следующем:</para>
|
||||
|
||||
<para>Сопровождающий владеет кодом и отвечает за него. Это означает, что
|
||||
он несет ответственность за исправление ошибок и закрывает сообщения о
|
||||
проблемах, имеющих отношение к этой части кода, а в случае программного
|
||||
обеспечения, взятого из третьих источников, соответственно отвечает за
|
||||
отслеживание новых версий.</para>
|
||||
|
||||
<para>Изменения в каталогах, для которых известен сопровождающий, прежде
|
||||
чем они будут внесены, должны быть посланы ему на рассмотрение. Только
|
||||
если сопровождающий не отвечает в течение достаточно большого периода
|
||||
времени на несколько посланий по электронной почте, разрешается внести
|
||||
изменения без участия сопровождающего. Однако рекомендуется, чтобы вы
|
||||
попытались передать изменения на рассмотрение кому-либо еще, если это
|
||||
вообще возможно.</para>
|
||||
|
||||
<para>Конечно же, нельзя назначать человека или группу лиц
|
||||
сопровождающими, если они не согласны выполнять эту работу. С другой
|
||||
стороны, необязательно это должен быть конкретный коммиттер, это может
|
||||
быть и группа людей.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="policies-contributed">
|
||||
<title>Программное обеспечение третьих сторон</title>
|
||||
|
||||
<para><emphasis>Текст предоставили &a.phk; и &a.obrien;. </emphasis></para>
|
||||
|
||||
<para>Июнь 1996.</para>
|
||||
|
||||
<para>Некоторые части дистрибутива FreeBSD состоят из программного
|
||||
обечпечения, которое сопровождается вне проекта FreeBSD. По
|
||||
историческим причинам мы называем такое программное обеспечение
|
||||
<emphasis>контрибуцированным</emphasis> (contributed), или третьих
|
||||
сторон. Примерами этого могут служить утилиты perl, gcc и
|
||||
patch.</para>
|
||||
|
||||
<para>За последние несколько лет для работы с таким программным
|
||||
обеспечением использовались различные методы, и все они имели свои
|
||||
достоинства и недостатки. Абсолютно подходящего метода так и не
|
||||
нашлось.</para>
|
||||
|
||||
<para>По этой причине после некоторых дебатов был выбран и признан
|
||||
<quote>официальным</quote> один из этих методов, который необходимо
|
||||
применять в будущем при импортировании такого рода программного
|
||||
обеспечения. Более того, настоятельно рекомендуется с течением времени
|
||||
перевести существующее программное обеспечение третьих сторон на этот
|
||||
метод, так как он имеет значительные преимущества перед старым методом,
|
||||
включая возможность легкого получения diff-файлов относительно
|
||||
<quote>официальных</quote> версий исходных текстов кем угодно (даже
|
||||
не имеющим доступа к cvs). Это делает данный метод гораздо проще
|
||||
в использовании при необходимости выдачи изменений изначальным
|
||||
разработчикам такого программного обеспечения.</para>
|
||||
|
||||
<para>В конце концов, однако, это касается тех, кто делает реальную
|
||||
работу. Если использование этой модели в конкретном случае не подходит
|
||||
для пакета, с которым работает человек, могут быть сделаны и
|
||||
исключения только с согласия основной команды разработчиков и при общем
|
||||
одобрении других разработчиков. Возможность сопровождения пакета в
|
||||
будущем будет являться ключевым моментом при принятии решений.</para>
|
||||
|
||||
<note>
|
||||
<para>Из-за досадных ограничений в дизайне формата файлов RCS и
|
||||
использовании веток поставщика в CVS, мелкие, тривиальные и/или
|
||||
косметические изменения <emphasis>сильно не рекомендуется</emphasis>
|
||||
в файлах, которые все еще отслеживаются в ветке поставщика. Это
|
||||
касается и <quote>исправления орфографических ошибок</quote> как
|
||||
относящихся к категории <quote>косметических</quote> и избегаемых
|
||||
для файлов с версиями 1.1.x.x. Рост объема хранилища, вызванный
|
||||
изменением в один символ, может оказаться весьма большим.</para>
|
||||
</note>
|
||||
|
||||
<para>В качестве примера того, как работает эта модель, будем
|
||||
использовать встраиваемый язык программирования
|
||||
<application>TCL</application>:</para>
|
||||
|
||||
<para>Каталог <filename>src/contrib/tcl</filename> содержит исходные
|
||||
тексты пакета в том виде, в котором они распространяются его
|
||||
создателями. Части, которые полностью не применимы во FreeBSD, могут
|
||||
быть удалены. В случае Tcl подкаталоги <filename>mac</filename>,
|
||||
<filename>win</filename> и <filename>compat</filename> были удалены
|
||||
перед операцией импортирования</para>
|
||||
|
||||
<para>Каталог <filename>src/lib/libtcl</filename> содержит только файл
|
||||
<filename>Makefile</filename> "в стиле bmake", который использует
|
||||
стандартные правила <filename>bsd.lib.mk</filename> make-файла для
|
||||
построения библиотеки и установки документации.</para>
|
||||
|
||||
<para>В каталоге <filename>src/usr.bin/tclsh</filename> размещаются
|
||||
make-файлы в стиле bmake, которые отвечают за построение и установку
|
||||
программы <command>tclsh</command> и связанных с ней справочных
|
||||
страниц при помощи стандартных правил из
|
||||
<filename>bsd.prog.mk</filename>.</para>
|
||||
|
||||
<para>Каталог <filename>src/tools/tools/tcl_bmake</filename> содержит
|
||||
несколько shell-скриптов, которые могут помочь при обновлении
|
||||
программного обеспечения tcl. Они не являются частью строящегося и
|
||||
исталлируемого программного обеспечения.</para>
|
||||
|
||||
<para>Здесь важно то, что каталог <filename>src/contrib/tcl</filename>
|
||||
создавался в соответствии с правилами: Предполагается, что он содержит
|
||||
исходнве тексты в том виде, в котором они распространяются (в
|
||||
соответствующей ветви поставщика CVS и без расширения ключевых слов
|
||||
RCS) с максимально малым количеством изменений, специфичных для
|
||||
FreeBSD. Утилита 'easy-import' на машине freefall поможет в
|
||||
импортировании, но если есть сомнения по поводу выполнения этой
|
||||
операции, то обязательно спросите совета и не действуйте слепо в
|
||||
расчете на то, что <quote>все сработает</quote>. CVS не прощает ошибок
|
||||
импортирования и для ликвидации последствий больших ошибок требуются
|
||||
значительные усилия.</para>
|
||||
|
||||
<para>Из-за ранее отмеченных ограничений дизайна веток поставщиков в CVS
|
||||
требуется, чтобы <quote>официальные</quote> патчи от разработчика
|
||||
были сначала применены к распространяемым исходным текстам, а затем
|
||||
результат снова импортирован в ветку поставщика. Официальные патчи
|
||||
никогда не должны применяться к версии, извлеченной из хранилища
|
||||
FreeBSD, а затем "коммититься", так как это привдет к рассинхронизации
|
||||
дерева производителя и усложнит импортирование будущих версий, так как
|
||||
возникнут конфликты.</para>
|
||||
|
||||
<para>Так как многие пакеты содержат файлы, имеющие значение при
|
||||
обеспечении совместимости с другими, отличными от FreeBSD архитектурами
|
||||
и окружениями, то разрешается удалять части дистрибутивного дерева,
|
||||
не представляющие интереса для FreeBSD в целях уменьшения занимаемого
|
||||
дискового пространства. Файлы, содержащие замечания о юридических
|
||||
правах и информацию о релизе, касающуюся остальных файлов, удаляться
|
||||
<emphasis>не</emphasis> должны.</para>
|
||||
|
||||
<para>Если это видится легким, то файлы <filename>Makefile</filename> в
|
||||
стиле <command>bmake</command> могут быть сгенерированы из
|
||||
дистрибутивного дерева автоматически некоторой утилитой, чем-то, что
|
||||
позволит еще проще обновляться до новой версии. Если это будет
|
||||
сделано, то обязательно поместите эту утилиту (если необходимо) в
|
||||
каталог <filename>src/tools</filename> вместе с самим портом, чтобы
|
||||
она была доступна будущим сопровождающим лицам.</para>
|
||||
|
||||
<para>В каталог <filename>src/contrib/tcl</filename> должен быть добавлен
|
||||
файл <filename>FREEBSD-upgrade</filename>, в котором нужно перечислить
|
||||
такие вещи:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Какие файлы были оставлены</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Где был взят оригинальный дистрибутив и/или на каком основном
|
||||
официальном сайте он находится.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Куда посылать патчи для разработчиков пакета</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Возможно, обзор сделанных изменений, специфичных для
|
||||
FreeBSD.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Однако, пожалуйста, не импортируйте
|
||||
<filename>FREEBSD-upgrade</filename> вместе с исходными текстами
|
||||
этого программного обеспечения. Вместо этого вы должны выполнить
|
||||
команды <command>cvs add FREEBSD-upgrade ; cvs ci</command> после
|
||||
первоначального импортирования. Ниже дается пример описания из
|
||||
каталога <filename>src/contrib/cpio</filename>:</para>
|
||||
|
||||
<programlisting>
|
||||
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
|
||||
</programlisting>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="policies-encumbered">
|
||||
<title>Нежелательные файлы</title>
|
||||
|
||||
<para>Иногда может быть необходимо включить некоторый нежелатеьный для
|
||||
нас файл в дерево исходных текстов FreeBSD. Например, если устройство
|
||||
требует загрузки в него некоторого маленького двоичного кода перед тем,
|
||||
как устройство заработает, и мы не имеем исходных текстов этого кода,
|
||||
то говорится, что двоичный файл является нежелательным. Для включения
|
||||
нежелательных файлов в дерево исходных текстов FreeBSD имеются
|
||||
следующие соглашения.</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Любой файл, интерпретируемый или выполняемый системным(и) CPU,
|
||||
не в форме исходного кода, является нежелательным.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Любой файл с лицензией, ограничивающей более, чем BSD или GNU,
|
||||
является нежелательным.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Файл, содержащий загружаемые двоичные данные, используемые
|
||||
аппаратным обеспечением, не являются нежелательными, если только
|
||||
к нему не применимы условия (1) или (2). Он должен быть сохранен в
|
||||
нейтральном к архитектуре формате ASCII (рекомендуется применить
|
||||
утилиты file2c или uuencode).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Люой нежелательный файл требует особое согласие со стороны
|
||||
<link linkend="staff-core">основной команды разработчиков</link> до
|
||||
того, как он будет добавлен в хранилище CVS.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Нежелательные файлы помещаются в каталог
|
||||
<filename>src/contrib</filename> или
|
||||
<filename>src/sys/contrib</filename>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Части одного модуля должны храниться вместе. Нет необходимости
|
||||
разбивать их, если только нет совместного использования с кодом,
|
||||
не являющимся нежелательным.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Объектные файлы именуются
|
||||
<filename><replaceable>arch</replaceable>/<replaceable>filename</replaceable>.o.uu></filename>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Файлы ядра;</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Должны всегда упоминаться в
|
||||
<filename>conf/files.*</filename> (для упрощения
|
||||
построения).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Должны всегда присутствовать в <filename>LINT</filename>,
|
||||
но <link linkend="staff-core">основная команда
|
||||
разработчиков</link> решает в каждом конкретном случае, должны
|
||||
ли они быть раскомментированы или нет. Конечно, позже <link
|
||||
linkend="staff-core">основная команда разработчиков</link>
|
||||
может изменить свое решение.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Вопрос о вхождении в состав релиза решается <link
|
||||
linkend="staff-who">инженером, ответственным за
|
||||
релиз</link>.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Файлы уровня пользователя;</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para><link linkend="staff-core">Основная команда
|
||||
разработчиков</link> решает, должен ли код стать частью
|
||||
выполнения команды <command>make world</command>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><link linkend="staff-who">Релиз-инженер</link> решает,
|
||||
войдут ли они в релиз.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="policies-shlib">
|
||||
<title>Динамические библиотеки</title>
|
||||
|
||||
<para><emphasis>Текст предоставили &a.asami;, &a.peter;, и &a.obrien; 9
|
||||
декабря 1996.</emphasis></para>
|
||||
|
||||
<para>Если вы добавляете поддержку динамических библиотек к порту или
|
||||
другой части программного обеспечения, которая этой возможностью не
|
||||
обладает, то номера версий должны назначаться по нижеследующим
|
||||
правилам. Как правило, получающиеся номера не имеют ничего общего с
|
||||
номером релиза программного обеспечения.</para>
|
||||
|
||||
<para>При построении динамической библиотеки используются три
|
||||
принципа:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Начинаем с <literal>1.0</literal></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Если есть изменение, которое имеет обратную совместимость,
|
||||
увеличиваем младший номер версии (заметьте, что системы ELF его
|
||||
игнорируют)</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Если есть изменение, не соблюдающее совместимость, увеличиваем
|
||||
старший номер версии</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>К примеру, добавление функций и исправление ошибок приводит к
|
||||
увеличению младшего номера версии, а удаление функций, изменение
|
||||
синтаксиса вызова функции и тому подобные изменения приводят к
|
||||
изменению старшего номера версии.</para>
|
||||
|
||||
<para>Следуйте схеме нумерации версий в форме старший.младший
|
||||
(<replaceable>x</replaceable>.<replaceable>y</replaceable>). Наш
|
||||
динамический загрузчик формата a.out не умеет нормально работать с
|
||||
номерами версий в форме
|
||||
<replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable>.
|
||||
Любой номер версии после <replaceable>y</replaceable> (то есть третье
|
||||
число) полностью игнорируется при сравнении номеров версий динамических
|
||||
библиотек для определения того, с какой библиотекой осуществлять
|
||||
компоновку. Если есть две динамические библиотеки, отличающиеся только
|
||||
<quote>микро</quote>-номером версии, то <command>ld.so</command> будет
|
||||
осуществлять компоновку с наибольшим номером. Другими словами: если
|
||||
вы компонуете с <filename>libfoo.so.3.3.3</filename>, то компоновщик
|
||||
запишет в заголовках только <literal>3.3</literal> и будет выполнять
|
||||
компоновку с любой библиотекой, начинающейся с
|
||||
<replaceable>libfoo.so.3</replaceable>.<replaceable>(все, что >=
|
||||
3)</replaceable>.<replaceable>(наибольшее из
|
||||
доступного)</replaceable>.</para>
|
||||
|
||||
<note>
|
||||
<para><command>ld.so</command> всегда будет использовать наибольшую
|
||||
<quote>младшую</quote> версию. Иными словами: он будет предпочитать
|
||||
использовать <filename>libc.so.2.2</filename>, а не
|
||||
<filename>libc.so.2.0</filename>, даже если программа изначально была
|
||||
скомпонована с <filename>libc.so.2.0</filename>.</para>
|
||||
</note>
|
||||
|
||||
<para>Вдобавок наш динамический компоновщик ELF совсем не работает с
|
||||
младшими версиями. Однако все же нужно указывать старший и младший
|
||||
номер версии, а наши файлы <filename>Makefile</filename> "сделают все
|
||||
как нужно" в зависимости от типа системы.</para>
|
||||
|
||||
<para>Для библиотек не в составе портов, имеется наше соглашение на
|
||||
изменение номера версии динамической библиотеки только один раз между
|
||||
релизами. Кроме того, есть договоренность на изменение старшего
|
||||
номера динамической библиотеки только один раз между главными релизами
|
||||
ОС. А именно: X.0 на (X+1).0. Когда вы делаете изменение в системной
|
||||
библиотеке, которое требует увеличения номера версии, посмотрите
|
||||
журналы коммитов изменений в файле <filename>Makefile</filename>.
|
||||
Коммиттер отвечает за то, что первое такое изменение с момента релиза
|
||||
приведет к обновлению номера версии динамической библиотеки в файле
|
||||
<filename>Makefile</filename>, а при других последующих изменениях
|
||||
этого бы не делалось.</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-declaration: "../chapter.decl"
|
||||
sgml-indent-data: t
|
||||
sgml-omittag: nil
|
||||
sgml-always-quote-attributes: t
|
||||
sgml-parent-document: ("../book.sgml" "part" "chapter")
|
||||
End:
|
||||
-->
|
||||
File diff suppressed because it is too large
Load diff
Loading…
Reference in a new issue