From ec5792c0b8f226e392226ccc5b56042c81b29b7a Mon Sep 17 00:00:00 2001 From: Warren Block Date: Mon, 9 Jan 2012 18:26:08 +0000 Subject: [PATCH] Narrow an overwide table, clarify some wording, fix header filenames in programlistings so they consistently end with a colon, split some long sentences in two, remove some extraneous commas and words, make a reference to the Developers Handbook a link, and fix title capitalization. Approved by: gjb (mentor) --- .../books/arch-handbook/boot/chapter.sgml | 62 ++++++++++--------- 1 file changed, 32 insertions(+), 30 deletions(-) diff --git a/en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml index b5257601a2..edd443232d 100644 --- a/en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml +++ b/en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml @@ -16,7 +16,7 @@ $FreeBSD$ - Bootstrapping and kernel initialization + Bootstrapping and Kernel Initialization Synopsis @@ -62,11 +62,11 @@ $FreeBSD$ using the table that follows. Please note that the actual data may differ from machine to machine: - + - may vary + Output (may vary) BIOS (firmware) messages @@ -184,7 +184,7 @@ Timecounter "i8254" frequency 1193182 Hz - <literal>boot0</literal> stage + <literal>boot0</literal> Stage MBR Take a look at the file /boot/boot0. @@ -269,7 +269,7 @@ Timecounter "i8254" frequency 1193182 Hz - <literal>boot2</literal> stage + <literal>boot2</literal> Stage You might wonder, why boot2 comes after boot0, and not boot1. Actually, there is a @@ -316,7 +316,7 @@ Timecounter "i8254" frequency 1193182 Hz The boot2 binary is created in special way: - sys/boot/i386/boot2/Makefile + sys/boot/i386/boot2/Makefile: boot2: boot2.ldr boot2.bin ${BTX}/btx/btx btxld -v -E ${ORG2} -f bin -b ${BTX}/btx/btx -l boot2.ldr \ -o boot2.ld -P 1 boot2.bin @@ -415,7 +415,7 @@ init.2: shr %bx # Handle this int? boot device, physical memory available, envp pointer etc. The definition for it is: - /usr/include/machine/bootinfo.h + /usr/include/machine/bootinfo.h: struct bootinfo { u_int32_t bi_version; u_int32_t bi_kernelname; /* represents a char * */ @@ -459,7 +459,7 @@ struct bootinfo { - <application>loader</application> stage + <application>loader</application> Stage loader is a BTX client as well. I will not describe it here in detail, there is a comprehensive @@ -476,10 +476,10 @@ struct bootinfo { - Kernel initialization + Kernel Initialization Let us take a look at the command that links the kernel. This - will help us identify the exact location where the loader passes + will help identify the exact location where the loader passes execution to the kernel. This location is the kernel's actual entry point. @@ -489,7 +489,7 @@ ld -elf -Bdynamic -T /usr/src/sys/conf/ldscript.i386 -export-dynamic \ <lots of kernel .o files> ELF - A few interesting things can be seen in this line. First, + A few interesting things can be seen here. First, the kernel is an ELF dynamically linked binary, but the dynamic linker for kernel is /red/herring, which is definitely a bogus file. Second, taking a look at the file @@ -513,11 +513,11 @@ ENTRY(btext) */ NON_GPROF_ENTRY(btext) - First what is done is the register EFLAGS is set to a - predefined value of 0x00000002, and then all the segment + First, the register EFLAGS is set to a + predefined value of 0x00000002. Then all the segment registers are initialized: - sys/i386/i386/locore.s + sys/i386/i386/locore.s: /* Don't trust what the BIOS gives for eflags. */ pushl $PSL_KERNEL popfl @@ -546,7 +546,7 @@ NON_GPROF_ENTRY(btext) This routine parses the parameters to the kernel passed from the bootstrap. The kernel may have been booted in 3 ways: by the loader, described above, by the - old disk boot blocks, and by the old diskless boot + old disk boot blocks, or by the old diskless boot procedure. This function determines the booting method, and stores the struct bootinfo structure into the kernel memory. @@ -597,7 +597,7 @@ NON_GPROF_ENTRY(btext) /* now running relocated at KERNBASE where the system is linked to run */ begin: - The function init386() is called, with + The function init386() is called with a pointer to the first free physical page, after that mi_startup(). init386 is an architecture dependent initialization function, and @@ -618,11 +618,11 @@ begin: init386() is defined in sys/i386/i386/machdep.c and performs - low-level initialization, specific to the i386 chip. The + low-level initialization specific to the i386 chip. The switch to protected mode was performed by the loader. The loader has created the very first task, in which the kernel - continues to operate. Before running straight away to the - code, I will enumerate the tasks the processor must complete + continues to operate. Before looking at the + code, consider the tasks the processor must complete to initialize protected mode execution: @@ -662,9 +662,9 @@ begin: parameters - What init386() first does is - initialize the tunable parameters passed from bootstrap. This - is done by setting the environment pointer (envp) and calling + init386() + initializes the tunable parameters passed from bootstrap + by setting the environment pointer (envp) and calling init_param1(). The envp pointer has been passed from loader in the bootinfo structure: @@ -682,19 +682,19 @@ begin: init_param2(), that are called from init386(): - sys/kern/subr_param.c + sys/kern/subr_param.c: hz = HZ; TUNABLE_INT_FETCH("kern.hz", &hz); TUNABLE_<typename>_FETCH is used to fetch the value from the environment: - /usr/src/sys/sys/kernel.h + /usr/src/sys/sys/kernel.h: #define TUNABLE_INT_FETCH(path, var) getenv_int((path), (var)) - Sysctl kern.hz is the system clock tick. Along with - this, the following sysctls are set by + Sysctl kern.hz is the system clock tick. + Additionally, these sysctls are set by init_param1(): kern.maxswzone, kern.maxbcache, kern.maxtsiz, kern.dfldsiz, kern.maxdsiz, kern.dflssiz, kern.maxssiz, kern.sgrowsiz. @@ -746,7 +746,7 @@ union descriptor gdt[NGDT * MAXCPU]; /* global descriptor table */ Interrupt Descriptor Table (IDT) The next step is to initialize the Interrupt Descriptor - Table (IDT). This table is to be referenced by the processor + Table (IDT). This table is referenced by the processor when a software or hardware interrupt occurs. For example, to make a system call, user application issues the INT 0x80 instruction. This is a software interrupt, so @@ -797,7 +797,7 @@ struct gate_descriptor *idt = &idt0[0]; /* interrupt descriptor table */ LDT, they are the system call gates and the user code and data selectors: - /usr/include/machine/segments.h + /usr/include/machine/segments.h: #define LSYS5CALLS_SEL 0 /* forced by intel BCS */ #define LSYS5SIGR_SEL 1 #define L43BSDCALLS_SEL 2 /* notyet */ @@ -844,7 +844,9 @@ struct gate_descriptor *idt = &idt0[0]; /* interrupt descriptor table */ } Although the sysinit framework is described in the - Developers' Handbook, I will discuss the internals of it. + Developers' + Handbook, I will discuss the internals of it. sysinit objects Every system initialization object (sysinit object) is @@ -885,7 +887,7 @@ SYSINIT(announce, SI_SUB_COPYRIGHT, SI_ORDER_FIRST, print_caddr_t, copyright)

MAKE_SET(), and that macro is the point where the all sysinit magic is hidden: - /usr/include/linker_set.h + /usr/include/linker_set.h: #define MAKE_SET(set, sym) \ static void const * const __set_##set##_sym_##sym = &sym; \ __asm(".section .set." #set ",\"aw\""); \