diff --git a/en_US.ISO8859-1/books/handbook/Makefile b/en_US.ISO8859-1/books/handbook/Makefile index 6c2205dd7a..254f1bb2b2 100644 --- a/en_US.ISO8859-1/books/handbook/Makefile +++ b/en_US.ISO8859-1/books/handbook/Makefile @@ -1,97 +1,95 @@ # -# $FreeBSD: doc/en_US.ISO8859-1/books/handbook/Makefile,v 1.39 2001/07/13 22:55:50 murray Exp $ +# $FreeBSD: doc/en_US.ISO8859-1/books/handbook/Makefile,v 1.40 2001/07/17 01:37:39 murray Exp $ # # Build the FreeBSD Handbook. # # ------------------------------------------------------------------------ # # Handbook-specific variables # # WITH_PGPKEYS The print version of the handbook only prints PGP # fingerprints by default. If you would like for the # entire key to be displayed, then set this variable. # This option has no affect on the HTML formats. # # ------------------------------------------------------------------------ MAINTAINER=nik@FreeBSD.org DOC?= book FORMATS?= html-split INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= IMAGES = advanced-networking/isdn-bus.eps IMAGES+= advanced-networking/isdn-twisted-pair.eps IMAGES+= advanced-networking/natd.eps # # SRCS lists the individual SGML files that make up the document. Changes # to any of these files will force a rebuild # # SGML content SRCS= book.sgml SRCS+= advanced-networking/chapter.sgml SRCS+= backups/chapter.sgml SRCS+= basics/chapter.sgml SRCS+= bibliography/chapter.sgml SRCS+= config/chapter.sgml SRCS+= boot/chapter.sgml SRCS+= contrib/chapter.sgml SRCS+= cutting-edge/chapter.sgml SRCS+= disks/chapter.sgml SRCS+= eresources/chapter.sgml SRCS+= install/chapter.sgml SRCS+= introduction/chapter.sgml SRCS+= kernelconfig/chapter.sgml -SRCS+= kernelopts/chapter.sgml SRCS+= l10n/chapter.sgml SRCS+= linuxemu/chapter.sgml SRCS+= mail/chapter.sgml SRCS+= mirrors/chapter.sgml SRCS+= pgpkeys/chapter.sgml SRCS+= ppp-and-slip/chapter.sgml SRCS+= printing/chapter.sgml SRCS+= security/chapter.sgml SRCS+= serialcomms/chapter.sgml SRCS+= sound/chapter.sgml -SRCS+= staff/chapter.sgml SRCS+= users/chapter.sgml SRCS+= x11/chapter.sgml SRCS+= ports/chapter.sgml # Entities SRCS+= authors.ent SRCS+= chapters.ent SYMLINKS= ${DESTDIR} index.html handbook.html # Turn on all the chapters. CHAPTERS?= ${SRCS:M*chapter.sgml} JADEFLAGS+= ${CHAPTERS:S/\/chapter.sgml//:S/^/-i chap./} # XXX The Handbook build currently overflows some internal, hardcoded # limits in pdftex. Until we split the Handbook up, build the PDF # version using ps2pdf instead of pdftex. book.tex-pdf: touch book.tex-pdf book.pdf: book.ps ps2pdf book.ps book.pdf DOC_PREFIX?= ${.CURDIR}/../../.. # # Handbook-specific variables # .if defined(WITH_PGPKEYS) JADEFLAGS+= -V withpgpkeys .endif .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/en_US.ISO8859-1/books/handbook/kerneldebug/Makefile b/en_US.ISO8859-1/books/handbook/kerneldebug/Makefile deleted file mode 100644 index a6d190e942..0000000000 --- a/en_US.ISO8859-1/books/handbook/kerneldebug/Makefile +++ /dev/null @@ -1,15 +0,0 @@ -# -# Build the Handbook with just the content from this chapter. -# -# $FreeBSD$ -# - -CHAPTERS= kerneldebug/chapter.sgml - -VPATH= .. - -MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX} - -DOC_PREFIX?= ${.CURDIR}/../../../.. - -.include "../Makefile" diff --git a/en_US.ISO8859-1/books/handbook/kerneldebug/chapter.sgml b/en_US.ISO8859-1/books/handbook/kerneldebug/chapter.sgml deleted file mode 100644 index d29fc84ca2..0000000000 --- a/en_US.ISO8859-1/books/handbook/kerneldebug/chapter.sgml +++ /dev/null @@ -1,638 +0,0 @@ - - - - Kernel Debugging - - Contributed by &a.paul; and &a.joerg; - - - Debugging a Kernel Crash Dump with <command>gdb</command> - - Here are some instructions for getting kernel debugging working on a - crash dump. They assume that you have enough swap space for a crash - dump. If you have multiple swap partitions and the first one is too - small to hold the dump, you can configure your kernel to use an - alternate dump device (in the config kernel line), or - you can specify an alternate using the - &man.dumpon.8; command. The best way to use &man.dumpon.8; is to set - the dumpdev variable in - /etc/rc.conf. Typically you want to specify one of - the swap devices specified in /etc/fstab. Dumps to - non-swap devices, tapes for example, are currently not supported. Config - your kernel using config . See Kernel Configuration for details on - configuring the FreeBSD kernel. - - Use the &man.dumpon.8; command to tell the kernel where to dump to - (note that this will have to be done after configuring the partition in - question as swap space via &man.swapon.8;). This is normally arranged - via /etc/rc.conf and /etc/rc. - Alternatively, you can hard-code the dump device via the - dump clause in the config line of - your kernel config file. This is deprecated and should be used only if - you want a crash dump from a kernel that crashes during booting. - - - In the following, the term gdb refers to - the debugger gdb run in kernel debug - mode. This can be accomplished by starting the - gdb with the option . In - kernel debug mode, gdb changes its prompt to - (kgdb). - - - - If you are using FreeBSD 3 or earlier, you should make a stripped - copy of the debug kernel, rather than installing the large debug - kernel itself: - - &prompt.root; cp kernel kernel.debug -&prompt.root; strip -g kernel - - This stage isn't necessary, but it is recommended. (In - FreeBSD 4 and later releases this step is performed automatically - at the end of the kernel make process.) - When the kernel has been stripped, either automatically or by - using the commands above, you may install it as usual by typing - make install. - - Note that older releases of FreeBSD (up to but not including - 3.1) used a.out kernels by default, which must have their symbol - tables permanently resident in physical memory. With the larger - symbol table in an unstripped debug kernel, this is wasteful. - Recent FreeBSD releases use ELF kernels where this is no longer a - problem. - - - If you are testing a new kernel, for example by typing the new - kernel's name at the boot prompt, but need to boot a different one in - order to get your system up and running again, boot it only into single - user state using the flag at the boot prompt, and - then perform the following steps: - - &prompt.root; fsck -p -&prompt.root; mount -a -t ufs # so your file system for /var/crash is writable -&prompt.root; savecore -N /kernel.panicked /var/crash -&prompt.root; exit # ...to multi-user - - This instructs &man.savecore.8; to use another kernel for symbol - name extraction. It would otherwise default to the currently running - kernel and most likely not do anything at all since the crash dump and - the kernel symbols differ. - - Now, after a crash dump, go to - /sys/compile/WHATEVER and run - gdb . From gdb do: - - symbol-file kernel.debug -exec-file /var/crash/kernel.0 -core-file /var/crash/vmcore.0 - - and voila, you can debug the crash dump using the kernel sources just - like you can for any other program. - - Here is a script log of a gdb session - illustrating the procedure. Long lines have been folded to improve - readability, and the lines are numbered for reference. Despite this, it - is a real-world error trace taken during the development of the pcvt - console driver. - - 1:Script started on Fri Dec 30 23:15:22 1994 - 2:&prompt.root; cd /sys/compile/URIAH - 3:&prompt.root; gdb -k kernel /var/crash/vmcore.1 - 4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel -...done. - 5:IdlePTD 1f3000 - 6:panic: because you said to! - 7:current pcb at 1e3f70 - 8:Reading in symbols for ../../i386/i386/machdep.c...done. - 9:(kgdb) where -10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767) -11:#1 0xf0115159 in panic () -12:#2 0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698) -13:#3 0xf010185e in db_fncall () -14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073) -15:#5 0xf0101711 in db_command_loop () -16:#6 0xf01040a0 in db_trap () -17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723) -18:#8 0xf019d2eb in trap_fatal (...) -19:#9 0xf019ce60 in trap_pfault (...) -20:#10 0xf019cb2f in trap (...) -21:#11 0xf01932a1 in exception:calltrap () -22:#12 0xf0191503 in cnopen (...) -23:#13 0xf0132c34 in spec_open () -24:#14 0xf012d014 in vn_open () -25:#15 0xf012a183 in open () -26:#16 0xf019d4eb in syscall (...) -27:(kgdb) up 10 -28:Reading in symbols for ../../i386/i386/trap.c...done. -29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\ -30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\ -31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\ -32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\ -33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\ -34:ss = -266427884}) (../../i386/i386/trap.c line 283) -35:283 (void) trap_pfault(&frame, FALSE); -36:(kgdb) frame frame->tf_ebp frame->tf_eip -37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done. -38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\ -39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403) -40:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); -41:(kgdb) list -42:398 -43:399 tp->t_state |= TS_CARR_ON; -44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */ -45:401 -46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200) -47:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); -48:404 #else -49:405 return ((*linesw[tp->t_line].l_open)(dev, tp, flag)); -50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */ -51:407 } -52:(kgdb) print tp -53:Reading in symbols for ../../i386/i386/cons.c...done. -54:$1 = (struct tty *) 0x1bae -55:(kgdb) print tp->t_line -56:$2 = 1767990816 -57:(kgdb) up -58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\ -59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126) -60: return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p)); -61:(kgdb) up -62:#2 0xf0132c34 in spec_open () -63:(kgdb) up -64:#3 0xf012d014 in vn_open () -65:(kgdb) up -66:#4 0xf012a183 in open () -67:(kgdb) up -68:#5 0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\ -69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\ -70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \ -71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \ -72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673) -73:673 error = (*callp->sy_call)(p, args, rval); -74:(kgdb) up -75:Initial frame selected; you cannot go up. -76:(kgdb) quit -77:&prompt.root; exit -78:exit -79: -80:Script done on Fri Dec 30 23:18:04 1994 - Comments to the above script: - - - - line 6: - - - This is a dump taken from within DDB (see below), hence the - panic comment because you said to!, and a rather - long stack trace; the initial reason for going into DDB has been a - page fault trap though. - - - - - line 20: - - - This is the location of function trap() - in the stack trace. - - - - - line 36: - - - Force usage of a new stack frame; this is no longer necessary - now. The stack frames are supposed to point to the right - locations now, even in case of a trap. - From looking at the code in source line 403, there is a - high probability that either the pointer access for - tp was messed up, or the array access was out of - bounds. - - - - - line 52: - - - The pointer looks suspicious, but happens to be a valid - address. - - - - - line 56: - - - However, it obviously points to garbage, so we have found our - error! (For those unfamiliar with that particular piece of code: - tp->t_line refers to the line discipline of - the console device here, which must be a rather small integer - number.) - - - - - - - Debugging a Crash Dump with DDD - - Examining a kernel crash dump with a graphical debugger like - ddd is also possible. Add the - option to the ddd command line you would use - normally. For example; - - &prompt.root; ddd -k /var/crash/kernel.0 /var/crash/vmcore.0 - - You should then be able to go about looking at the crash dump using - ddd's graphical interface. - - - - Post-Mortem Analysis of a Dump - - What do you do if a kernel dumped core but you did not expect it, - and it is therefore not compiled using config -g? Not - everything is lost here. Do not panic! - - Of course, you still need to enable crash dumps. See above on the - options you have to specify in order to do this. - - Go to your kernel config directory - (/usr/src/sys/arch/conf) - and edit your configuration file. Uncomment (or add, if it does not - exist) the following line - - makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols - - Rebuild the kernel. Due to the time stamp change on the Makefile, - there will be some other object files rebuild, for example - trap.o. With a bit of luck, the added - option will not change anything for the generated - code, so you will finally get a new kernel with similar code to the - faulting one but some debugging symbols. You should at least verify the - old and new sizes with the &man.size.1; command. If there is a - mismatch, you probably need to give up here. - - Go and examine the dump as described above. The debugging symbols - might be incomplete for some places, as can be seen in the stack trace - in the example above where some functions are displayed without line - numbers and argument lists. If you need more debugging symbols, remove - the appropriate object files and repeat the gdb - session until you know enough. - - All this is not guaranteed to work, but it will do it fine in most - cases. - - - - On-Line Kernel Debugging Using DDB - - While gdb as an off-line debugger provides a very - high level of user interface, there are some things it cannot do. The - most important ones being breakpointing and single-stepping kernel - code. - - If you need to do low-level debugging on your kernel, there is an - on-line debugger available called DDB. It allows to setting - breakpoints, single-stepping kernel functions, examining and changing - kernel variables, etc. However, it cannot access kernel source files, - and only has access to the global and static symbols, not to the full - debug information like gdb. - - To configure your kernel to include DDB, add the option line - - options DDB - - to your config file, and rebuild. (See Kernel Configuration for details on - configuring the FreeBSD kernel. - - - If you have an older version of the boot blocks, your - debugger symbols might not be loaded at all. Update the boot blocks; - the recent ones load the DDB symbols automagically.) - - - Once your DDB kernel is running, there are several ways to enter - DDB. The first, and earliest way is to type the boot flag - right at the boot prompt. The kernel will start up - in debug mode and enter DDB prior to any device probing. Hence you can - even debug the device probe/attach functions. - - The second scenario is a hot-key on the keyboard, usually - Ctrl-Alt-ESC. For syscons, this can be remapped; some of the - distributed maps do this, so watch out. There is an option available - for serial consoles that allows the use of a serial line BREAK on the - console line to enter DDB (options BREAK_TO_DEBUGGER - in the kernel config file). It is not the default since there are a lot - of low quality serial adapters around that gratuitously generate a BREAK - condition, for example when pulling the cable. - - The third way is that any panic condition will branch to DDB if the - kernel is configured to use it. For this reason, it is not wise to - configure a kernel with DDB for a machine running unattended. - - The DDB commands roughly resemble some gdb - commands. The first thing you probably need to do is to set a - breakpoint: - - b function-name -b address - - Numbers are taken hexadecimal by default, but to make them distinct - from symbol names; hexadecimal numbers starting with the letters - a-f need to be preceded with 0x - (this is optional for other numbers). Simple expressions are allowed, - for example: function-name + 0x103. - - To continue the operation of an interrupted kernel, simply - type: - - c - - To get a stack trace, use: - - trace - - - Note that when entering DDB via a hot-key, the kernel is currently - servicing an interrupt, so the stack trace might be not of much use - for you. - - - If you want to remove a breakpoint, use - - - del -del address-expression - - The first form will be accepted immediately after a breakpoint hit, - and deletes the current breakpoint. The second form can remove any - breakpoint, but you need to specify the exact address; this can be - obtained from: - - show b - - To single-step the kernel, try: - - s - - This will step into functions, but you can make DDB trace them until - the matching return statement is reached by: - - n - - - This is different from gdb's - next statement; it is like gdb's - finish. - - - To examine data from memory, use (for example): - - x/wx 0xf0133fe0,40 -x/hd db_symtab_space -x/bc termbuf,10 -x/s stringbuf - - for word/halfword/byte access, and hexadecimal/decimal/character/ string - display. The number after the comma is the object count. To display - the next 0x10 items, simply use: - - x ,10 - - Similarly, use - - x/ia foofunc,10 - - to disassemble the first 0x10 instructions of - foofunc, and display them along with their offset - from the beginning of foofunc. - - To modify memory, use the write command: - - w/b termbuf 0xa 0xb 0 -w/w 0xf0010030 0 0 - - The command modifier - (b/h/w) - specifies the size of the data to be written, the first following - expression is the address to write to and the remainder is interpreted - as data to write to successive memory locations. - - If you need to know the current registers, use: - - show reg - - Alternatively, you can display a single register value by e.g. - - p $eax - - and modify it by: - - set $eax new-value - - Should you need to call some kernel functions from DDB, simply - say: - - call func(arg1, arg2, ...) - - The return value will be printed. - - For a &man.ps.1; style summary of all running processes, use: - - ps - - Now you have examined why your kernel failed, and you wish to - reboot. Remember that, depending on the severity of previous - malfunctioning, not all parts of the kernel might still be working as - expected. Perform one of the following actions to shut down and reboot - your system: - - panic - - This will cause your kernel to dump core and reboot, so you can - later analyze the core on a higher level with gdb. This command - usually must be followed by another continue - statement. - - call boot(0) - - Which might be a good way to cleanly shut down the running system, - sync() all disks, and finally reboot. As long as - the disk and file system interfaces of the kernel are not damaged, this - might be a good way for an almost clean shutdown. - - call cpu_reset() - - is the final way out of disaster and almost the same as hitting the - Big Red Button. - - If you need a short command summary, simply type: - - help - - However, it is highly recommended to have a printed copy of the - &man.ddb.4; manual page ready for a debugging - session. Remember that it is hard to read the on-line manual while - single-stepping the kernel. - - - - On-Line Kernel Debugging Using Remote GDB - - This feature has been supported since FreeBSD 2.2, and it is - actually a very neat one. - - GDB has already supported remote debugging for - a long time. This is done using a very simple protocol along a serial - line. Unlike the other methods described above, you will need two - machines for doing this. One is the host providing the debugging - environment, including all the sources, and a copy of the kernel binary - with all the symbols in it, and the other one is the target machine that - simply runs a similar copy of the very same kernel (but stripped of the - debugging information). - - You should configure the kernel in question with config - -g, include into the configuration, and - compile it as usual. This gives a large blurb of a binary, due to the - debugging information. Copy this kernel to the target machine, strip - the debugging symbols off with strip -x, and boot it - using the boot option. Connect the serial line - of the target machine that has "flags 080" set on its sio device - to any serial line of the debugging host. - Now, on the debugging machine, go to the compile directory of the target - kernel, and start gdb: - - &prompt.user; gdb -k kernel -GDB is free software and you are welcome to distribute copies of it - under certain conditions; type "show copying" to see the conditions. -There is absolutely no warranty for GDB; type "show warranty" for details. -GDB 4.16 (i386-unknown-freebsd), -Copyright 1996 Free Software Foundation, Inc... -(kgdb) - - Initialize the remote debugging session (assuming the first serial - port is being used) by: - - (kgdb) target remote /dev/cuaa0 - - Now, on the target host (the one that entered DDB right before even - starting the device probe), type: - - Debugger("Boot flags requested debugger") -Stopped at Debugger+0x35: movb $0, edata+0x51bc -db> gdb - - DDB will respond with: - - Next trap will enter GDB remote protocol mode - - Every time you type gdb, the mode will be toggled - between remote GDB and local DDB. In order to force a next trap - immediately, simply type s (step). Your hosting GDB - will now gain control over the target kernel: - - Remote debugging using /dev/cuaa0 -Debugger (msg=0xf01b0383 "Boot flags requested debugger") - at ../../i386/i386/db_interface.c:257 -(kgdb) - - You can use this session almost as any other GDB session, including - full access to the source, running it in gud-mode inside an Emacs window - (which gives you an automatic source code display in another Emacs - window) etc. - - - - Debugging Loadable Modules Using GDB - - When debugging a panic that occurred within a module, or - using remote GDB against a machine that uses dynamic modules, - you need to tell GDB how to obtain symbol information for those - modules. - - First, you need to build the module(s) with debugging - information: - - &prompt.root; cd /sys/modules/linux -&prompt.root; make clean; make COPTS=-g - - If you are using remote GDB, you can run - kldstat on the target machine to find out - where the module was loaded: - - &prompt.root; kldstat -Id Refs Address Size Name - 1 4 0xc0100000 1c1678 kernel - 2 1 0xc0a9e000 6000 linprocfs.ko - 3 1 0xc0ad7000 2000 warp_saver.ko - 4 1 0xc0adc000 11000 linux.ko - - If you are debugging a crash dump, you'll need to walk the - linker_files list, starting at - linker_files->tqh_first and following the - link.tqe_next pointers until you find the - entry with the filename you are looking for. - The address member of that entry is the load - address of the module. - - Next, you need to find out the offset of the text section - within the module: - - &prompt.root; objdump --section-headers /sys/modules/linux/linux.ko | grep text - 3 .rel.text 000016e0 000038e0 000038e0 000038e0 2**2 - 10 .text 00007f34 000062d0 000062d0 000062d0 2**2 - - The one you want is the .text section, - section 10 in the above example. The fourth hexadecimal field - (sixth field overall) is the offset of the text section within - the file. Add this offset to the load address of the module to - obtain the relocation address for the module's code. In our - example, we get 0xc0adc000 + 0x62d0 = 0xc0ae22d0. Use the - add-symbol-file command in GDB to tell the - debugger about the module: - - (kgdb) add-symbol-file /sys/modules/linux/linux.ko 0xc0ae22d0 -add symbol table from file "/sys/modules/linux/linux.ko" at text_addr = 0xc0ae22d0? -(y or n) y -Reading symbols from /sys/modules/linux/linux.ko...done. -(kgdb) - - You should now have access to all the symbols in the - module. - - - - Debugging a Console Driver - - Since you need a console driver to run DDB on, things are more - complicated if the console driver itself is failing. You might remember - the use of a serial console (either with modified boot blocks, or by - specifying at the Boot: prompt), - and hook up a standard terminal onto your first serial port. DDB works - on any configured console driver, of course also on a serial - console. - - - - - diff --git a/en_US.ISO8859-1/books/handbook/staff/Makefile b/en_US.ISO8859-1/books/handbook/staff/Makefile deleted file mode 100644 index 2d9e5275ea..0000000000 --- a/en_US.ISO8859-1/books/handbook/staff/Makefile +++ /dev/null @@ -1,15 +0,0 @@ -# -# Build the Handbook with just the content from this chapter. -# -# $FreeBSD$ -# - -CHAPTERS= staff/chapter.sgml - -VPATH= .. - -MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX} - -DOC_PREFIX?= ${.CURDIR}/../../../.. - -.include "../Makefile" diff --git a/en_US.ISO8859-1/books/handbook/staff/chapter.sgml b/en_US.ISO8859-1/books/handbook/staff/chapter.sgml deleted file mode 100644 index f806b1f3e5..0000000000 --- a/en_US.ISO8859-1/books/handbook/staff/chapter.sgml +++ /dev/null @@ -1,1419 +0,0 @@ - - - - - - FreeBSD Project Staff - - The FreeBSD Project is managed and operated by the following groups of - people: - - - The FreeBSD Core Team - - The FreeBSD core team constitutes the project's Board of - Directors, responsible for deciding the project's overall goals - and direction as well as managing specific - areas of the FreeBSD project landscape. - - (in alphabetical order by last name): - - - - &a.asami; - - - - &a.dg; - - - - &a.jkh; - - - - &a.grog; - - - - &a.imp; - - - - &a.dfr; - - - - &a.msmith; - - - - &a.rwatson; - - - - &a.peter; - - - - - - - - The FreeBSD Developers - - These are the people who have commit privileges and do the - engineering work on the FreeBSD source tree. All core team members are - also developers. - - - - &a.akiyama; - - - - &a.jmas; - - - - &a.will; - - - - &a.ugen; - - - - &a.toshi; - - - - &a.babkin; - - - - &a.dbaker; - - - - &a.jhb; - - - - &a.dmlb; - - - - &a.mike; - - - - &a.mbarkah; - - - - &a.rvb; - - - - &a.dougb; - - - - &a.tobez; - - - - &a.stb; - - - - &a.pb; - - - - &a.abial; - - - - &a.jb; - - - - &a.nbm; - - - - &a.mb; - - - - &a.bbraun; - - - - &a.jmb; - - - - &a.torstenb; - - - - &a.wilko; - - - - &a.jake; - - - - &a.dburr; - - - - &a.adrian; - - - - &a.dwcjr; - - - - &a.charnier; - - - - &a.jon; - - - - &a.luoqi; - - - - &a.ache; - - - - &a.ejc; - - - - &a.kjc; - - - - &a.cjh; - - - - &a.cjc; - - - - &a.nik; - - - - &a.archie; - - - - &a.chris; - - - - &a.alc; - - - - &a.cracauer; - - - - &a.dec; - - - - &a.pds; - - - - &a.adam; - - - - &a.brooks; - - - - &a.bsd; - - - - &a.jwd; - - - - &a.dillon; - - - - &a.mdodd; - - - - &a.dd; - - - - &a.iedowse; - - - - &a.gad; - - - - &a.dufault; - - - - &a.uhclem; - - - - &a.tegge; - - - - &a.deischen; - - - - &a.eivind; - - - - &a.julian; - - - - &a.rse; - - - - &a.ue; - - - - &a.ru; - - - - &a.se; - - - - &a.bde; - - - - &a.jasone; - - - - &a.sef; - - - - &a.jedgar; - - - - &a.green; - - - - &a.fenner; - - - - &a.lioux; - - - - &a.jfieber; - - - - &a.jfitz; - - - - &a.scrappy; - - - - &a.lars; - - - - &a.dirk; - - - - &a.sf; - - - - &a.shige; - - - - &a.billf; - - - - &a.furuta; - - - - &a.gallatin; - - - - &a.patrick; - - - - &a.tg; - - - - &a.gibbs; - - - - &a.brandon; - - - - &a.gioria; - - - - &a.graichen; - - - - &a.cg; - - - - &a.rgrimes; - - - - &a.jmg; - - - - &a.hanai; - - - - &a.roger; - - - - &a.mharo; - - - - &a.dannyboy; - - - - &a.thepish; - - - - &a.jhay; - - - - &a.sheldonh; - - - - &a.mikeh; - - - - &a.helbig; - - - - &a.ghelmer; - - - - &a.erich; - - - - &a.chm; - - - - &a.nhibma; - - - - &a.flathill; - - - - &a.orion; - - - - &a.pho; - - - - &a.horikawa; - - - - &a.hosokawa; - - - - &a.jeh; - - - - &a.hsu; - - - - &a.foxfair; - - - - &a.tom; - - - - &a.mph; - - - - &a.imura; - - - - &a.shin; - - - - &a.itojun; - - - - &a.iwasaki; - - - - &a.mjacob; - - - - &a.keith; - - - - &a.gj; - - - - &a.trevor; - - - - &a.phk; - - - - &a.tomsoft; - - - - &a.joe; - - - - &a.cokane; - - - - &a.kato; - - - - &a.kris; - - - - &a.kiri; - - - - &a.andreas; - - - - &a.lkoeller; - - - - &a.motoyuki; - - - - &a.jkoshy; - - - - &a.kuriyama; - - - - &a.alex; - - - - &a.chern; - - - - &a.reg; - - - - &a.jlemon; - - - - &a.truckman; - - - - &a.ijliao; - - - - &a.lile; - - - - &a.clive; - - - - &a.kevlo; - - - - &a.scottl; - - - - &a.ade; - - - - &a.jmacd; - - - - &a.smace; - - - - &a.bmah; - - - - &a.dwmalone; - - - - &a.mckay; - - - - &a.mckusick; - - - - &a.eric; - - - - &a.ken; - - - - &a.dinoex; - - - - &a.hm; - - - - &a.sanpei; - - - - &a.bmilekic; - - - - &a.mita; - - - - &a.non; - - - - &a.jim; - - - - &a.marcel; - - - - &a.dan; - - - - &a.tmm; - - - - &a.amurai; - - - - &a.markm; - - - - &a.rich; - - - - &a.knu; - - - - &a.nakai; - - - - &a.max; - - - - &a.newton; - - - - &a.rnordier; - - - - &a.davidn; - - - - &a.obrien; - - - - &a.danny; - - - - &a.okazaki; - - - - &a.olgeni; - - - - &a.ljo; - - - - &a.onoe; - - - - &a.marko; - - - - &a.gpalmer; - - - - &a.fsmp; - - - - &a.smpatel; - - - - &a.cp; - - - - &a.wpaul; - - - - &a.mp; - - - - &a.alfred; - - - - &a.roam; - - - - &a.wes; - - - - &a.cpiazza; - - - - &a.pirzyk; - - - - &a.jdp; - - - - &a.bp; - - - - &a.steve; - - - - &a.mpp; - - - - &a.markp; - - - - &a.darrenr; - - - - &a.csgr; - - - - &a.greid; - - - - &a.martin; - - - - &a.benno; - - - - &a.luigi; - - - - &a.paul; - - - - &a.roberto; - - - - &a.chuckr; - - - - &a.jesusr; - - - - &a.guido; - - - - &a.groudier; - - - - &a.dima; - - - - &a.asmodai; - - - - &a.ps; - - - - &a.sada; - - - - &a.hrs; - - - - &a.wsanchez; - - - - &a.nsayer; - - - - &a.sos; - - - - &a.wosch; - - - - &a.schweikh; - - - - &a.dick; - - - - &a.jseger; - - - - &a.semenu; - - - - &a.gshapiro; - - - - &a.shiba; - - - - &a.tshiozak; - - - - &a.simokawa; - - - - &a.vanilla; - - - - &a.silby; - - - - &a.shafeeq; - - - - &a.demon; - - - - &a.jesper; - - - - &a.msmith; - - - - &a.ben; - - - - &a.nsouch; - - - - &a.issei; - - - - &a.des; - - - - &a.sobomax; - - - - &a.dcs; - - - - &a.brian; - - - - &a.mks; - - - - &a.stark; - - - - &a.murray; - - - - &a.sumikawa; - - - - &a.gsutter; - - - - &a.unfurl; - - - - &a.nyan; - - - - &a.tanimura; - - - - &a.taoka; - - - - &a.mtaylor; - - - - &a.dt; - - - - &a.mi; - - - - &a.yar; - - - - &a.cwt; - - - - &a.pst; - - - - &a.ume; - - - - &a.rv; - - - - &a.hoek; - - - - &a.nectar; - - - - &a.jayanth; - - - - &a.wjv; - - - - &a.bean; - - - - &a.swallace; - - - - &a.takawata; - - - - &a.assar; - - - - &a.dwhite; - - - - &a.nate; - - - - &a.wollman; - - - - &a.keichii; - - - - &a.joerg; - - - - &a.kbyanc; - - - - &a.uch; - - - - &a.yokota; - - - - &a.andy; - - - - &a.zarzycki; - - - - &a.phantom; - - - - &a.jmz; - - - - - - - - - The FreeBSD Documentation Project - - The FreeBSD - Documentation Project is responsible for a number of different - services, each service being run by an individual and his - deputies (if any): - - - - Documentation Project Architect - - - &a.nik; - - - - - Handbook Editor - - - &a.jim; - - - - - FAQ Editor - - - &a.faq; - - - - - News Editor - - - &a.jim; - - - - - - In the Press Editor - - - &a.jkoshy; - - - - - FreeBSD Really-Quick NewsLetter Editor - - - Chris Coleman chrisc@vmunix.com - - - - - Gallery Editor - - - &a.phantom; - - - - - Commercial Editor - - - &a.phantom; - - - - - Web Changes Editor - - - &a.www; - - - -]]> - - - User Groups Editor - - - &a.grog; - - - - - FreeBSD Projects and Tasklist Editor - - - &a.asmodai; - - - - - FreeBSD Java Project - - - &a.patrick; - - - - - LinuxDoc to DocBook conversion - - - &a.nik; - - - - - - - Who is Responsible for What - - - - Documentation - Project Manager - - - &a.nik; - - - - - Boot blocks - - - &a.rnordier;, &a.jhb; - - - - - Boot loader - - - &a.dcs; - &a.jhb; - - - - - Internationalization - - - &a.ache; - - - - - Postmaster - - - &a.jmb; - - - - - Release Coordinator - - - &a.jkh; - - - - - Public Relations & Corporate Liaison - - - &a.jkh; - - - - - Security - Officer - - - &a.kris; - - - - - Source - Repository Managers - - - Principal: &a.peter; - - Assistant: &a.jdp; - - - - - Ports - Manager - - - &a.asami; - - - - - Standards - - - &a.wollman; - - - - - XFree86 Project, Inc. Liaison - - - &a.rich; - - - - - GNATS - Administrator - - - &a.steve; - - - - - - - - -