I. Bootloader guides Linux on the Alpha / AXP platform, there are usually two methods, one is guided by MILO and other similar boot procedures, and the other is direct guided by Firmware. MILO features are similar to LILO of the i386 platform, but there are basic disk drivers (such as IDE, SCSI, etc.), as well as common file system drivers (such as EXT2, ISO9660, etc.), Firmware has Arc, SRM, ARC With a class BIOS interface, there is even multiple boot settings; while SRM has a powerful command line interface, and the user can use the boot and other command boot systems on the console. Arc has a partition concept, so you can access the first area of the partition; and the SRM can only control the first area of the disk. Both FIRMWAREs can boot Linux by booting MILO, or directly booting the boot code of Linux.
"Arch / alpha / boot" is a file for the LINUX Bootloader, "ARCH / ALPHA / BOOT". "Head.s" file provides a call entry to OSF PAL / 1, which will be compiled after the guiding sector (ARC partition region or SRM disk 0 sector), which is initialized after the control is initialized some data structure , Then turn the control to start_kernel () in "main.c", start_kernel () to output some prompts to the console, call PAL_init () to initialize the PAL code, call openboot () Open the boot device (by reading the firmware environment), Call Load () Loads the core code to start_addr (see "include / asm-alpha / system.h"), then load the core boot parameters in the Firmware into ZERO_PAGE (0), and finally call runkernel () to control the control 0x100000's kernel, the BootLoader section ends. "Arch / alpha / boot / bootp.c" is based on "main.c", which can replace "main.c" and "Head.s" to generate bootloader boots for BootP protocol networks.
All "SRM_" functions used in BootLoader are defined in "Arch / Alpha / LIB /".
The above Boot method is the simplest way that does not require other tools to boot the kernel, provided in accordance with Makefile guidance, generate bootimage files, containing the BootLoader and VMLinux mentioned above, then write bootimage to self Disk boot sector starting position.
When using the boot program such as MILO to boot Linux, it is not necessary to use the bootloader described above, but only VMLinux or VMLinux.gz, the boot sector actively decompresses the load-loaded core to 0x1000 (small kernel) or 0x100000 (large kernel), and Direct access to the kernel boot portion, that is, the second section of this article.
For the i386 platform I386 system, there are generally BIOS to do initial boot work, that is, load the first sector of the first guileable partition in the four primary partition tables on the real mode address 0x7c00, and then control the control Give it.
In the "Arch / I386 / Boot" directory, bootsect.s is the assembly source code for generating the boot sector, which first copies yourself to 0x90000, and then copy the next setup section (second sector) to 0x90200 , Copy the true kernel code to 0x100000. These copying movements are premise with bootsect.s, setup.s, and VMLinux in the disk, that is, our BZIMAGE file or zimage file is organized in order in Bootsect, Setup, Vmlinux, and stores Among the continuous disk sectors of the first region of the guide partition. After Bootsect.s completes the loading action, you jump directly to 0x90200, which is the program entry of Setup.s. The main function of Setup.s is to copy system parameters (including memory, disk, etc.) to 0x90000-0x901FF memory, which is the place where bootsect.s is stored, and it will be overwritten by the system parameters. These parameters will be read by code in the protection mode.
In addition, setup.s also contains code in Video.s, detects and sets the display and display mode. Finally, setup.s converts the system to the protection mode and jumps to 0x100000 (for the BZImage format is the core boot code for the 0x100000, the zimage format is 0x1000), and the bootloader process ends.
There is no change in the 2.4.x version of the core.
Two .kernel guides the entrance
Under the link script control of Arch / Alpha / VMLinux.lds, the link is placed on __start in "Arch / alpha / kernel / head.s", so when the bootloader jumps to 0x100000, __start The code begins to execute. __start's code is simple, just set the global variable, then jump to start_kernel. Start_kernel () is an ASMLinkage function in "init / main.c", to this, the startup process is transferred to the architectural unrelated general C code.
For the I386 platform in the i386 architecture, because i386 itself needs more settings in "Arch / alpha / kernel / head.s", it is finally transferred through Call Symbol_name (start_kernel) to start_kernel () this system The structure-independent function is executed.
The difference is that in the I386 system, when the kernel is compressed in the form of BZImage, it is necessary to pre-process bootsect.s and setup.s when the large core mode (__big_kernel__) is compressed, and use $ (CPP) processing by using the large-core mode. Bbootsect.s and bsetup.s, then build the corresponding .o file, and use the "Arch / I386 / Boot / Compressed / Build.c" build tool to generate the actual kernel (uncompressed, including Kernel Head.s code) synthesized with Head.s and Misc.c under "Arch / I386 / Boot / compressed", where Head.s replaced the "Arch / I386 / Kernel / Head.s" location, By bootloader boot execution (Startup_32 entrance), then it calls the Dec.c () function, using the gunzip defined in "lib / inflate.c" to extract the kernel to 0x100000, and go to it on it " STARTUP_32 code in Arch / I386 / kernel / head.s. There is no change in the 2.4.x version of the core.
II. Core Data Structure Initialization - Core Boot First Some START_KERNEL () calls a series of initialization functions to complete the set of kernel itself. These actions are public, and some will be executed.
In the start_kernel () function, output Linux version information (Printk (Linux_banner) settings related to the architecture (SETUP_ARCH ()) page structure initialization (Paging_init ()) uses "Arch / Alpha / Kernel / Entry.s" The entry point setting system self-trapping port (trap_init ()) uses the alpha_mv structure and the entry initialization system IRQ (Init_IRQ ()) core process scheduler initialization (including initializing several default bottom-hald, sched_init () The time, the timer is initialized (including reading the CMOS clock, estimating the frequency, initial timer interrupt, etc., TIME_INIT ()) extract and analyze the core startup parameters (read parameters from environment variables, set the corresponding flag waiting to process, (PARSE_OPTIONS ()) Console Initialization (for output information, initialization, console_init ()) Analyzer data structure initialization (Prof_Buffer and Prof_LEN variable) core Cache initialization (describe cache information Cache, KMEM_CACHE_INIT ()) Delay calibration ( Get Clock Jiffies Delayed with CPU Words Ticks, Calibrate_DELAY ()) Memory Initialization (Set the Inventory Proceedings and Page Item Attive Value, MEM_INIT ()) creates and sets internal and universal cache ("SLAB_CACHE", KMEM_CACHE_SIZES_INIT ()) creation Uid TaskCount SLAB CACHE ("UID_Cache", uidcache_init ()) Creates a file cache ("Files_Cache", FileScache_init ()) Creates a directory cache ("DENTRY_CACHE", DCACHE_INIT ()) Creates Cache related to the virtual memory ("VM_Area_Struct", " MM_STRUCT ", VMA_INIT ()) Block Device Read Write Buffer Initialization (Create" Buffer_Head "Cache User Accelerate Acceleration Access, Buffer_init ()) Create Page Cache (Memory Page Hash Table Initialization, Page_Cache_init ()) Create Signal Queu Cache (" Signal_Queue ", Sign_init ()) Initialize memory inode table (Inode_init ()) creates a memory file descriptor (" Filp_Cache ", File_Tabl E_INIT ()) Check the architecture vulnerability (for alpha, this function is empty, check_bugs ()) SMP machine The remaining CPU (in addition to the current boot CPU) initialization (for the kernel that does not configure SMP, this function is empty, SMP_init ()) startup INIT process (create the first core thread,
Call the init () function, the original execution sequence calls CPU_IDLE () Waiting schedule, init ()) to this start_kernel () end, the basic core environment has been established. The kernel startup process on the I386 platform I386 platform is basically the same, and the difference is mainly implemented.
For the 2.4.x version of the kernel 2.4.x, it is relatively large, but the basic process has not changed, and the change is a specific implementation of each data structure, such as Cache.
IV. Peripheral initialization - kernel boot second part init () function as core thread, first lock the kernel (valid only to SMP machine), then call DO_BASIC_SETUP () to complete the peripheral and its driver loading and initialization. The process is as follows:
Bus initialization (such as PCI_Init ()) network initialization (initialization network data structure, including SK_INIT (), SKB_INIT () and Proto_init () three parts, in Proto_init (), the initialization process of all protocols included in the Protocols structure, SOCK_INIT ()) Create a BDFlush core thread (BDFlush () process resident core space, wakes up by the core to clean the written memory buffer, when bdflush () is started by kernel_thread (), it is named KFLUSHD) creation KUPDATE Core Thread () Process Remote Core Space, executed by the core, updating the information in the memory buffer to disk, updated content including super block and inode table) Set and start the core tuning thread KSwapd In order to prevent the version information from the middle of the other information, the core line calls KSWAPD_SETUP () Set the required environment, then create a KSWAPD core thread) Create an event management core thread (START_CONTEXT_THREAD () function launch the context_thread () process And rename it as keventd) device initialization (including PaRPORT_INIT (), Character Device BLK_DEV_INIT (), block device SCSI_DEV_INIT (), SCSI device SCSI_DEV_INIT (), network device NET_DEV_INIT (), disk initialization and partition check, etc., Device_Setup () Perform file format settings (binfmt_setup ()) launched a function using the __initcall identity (convenient, core developer add boot function, do_initcalls ()) file system initialization (filesystem_setup ()) Install the root file system (Mount_Root ()) to this DO_BASIC_SETUP () Function Returns INIT (), after the release launch memory segment (free_initmem ()) and after the kernel unlock, INIT () opens / dev / console device, redirect stdin, stdout, and stderr to the console, finally, search file system The init program (or program specified by the init = command line parameter) and loads the init program using the Execve () system call.
The init () function is over, the kernel's boot section is over, this first thread created by start_kernel () has become a process in a user mode. There is six run entities in the system:
START_kernel () itself is active, which is actually a "handmade" thread that enters the CPU_idle () loop after creating the init () thread, it does not appear in the process (thread) list , Created by start_kernel (), currently in a user state, load the init program KFlushd core thread, created by the init thread, run the bdflush () function kupdate core thread, created by the init thread, run the kupdate () function in the core state KSWAPD core thread, created by the init thread, running the kswapd () function KEVENTD core thread in the core state, created by the init thread, the core state is running substantially the same as the I386 platform.
For the startup process of this part of the 2.4.x version of the core, there is a lot of simplified, the default independent initialization process is only available (SOCK_INIT ()) and creating an event management core thread, while other initialization required All using the __initcall () macro is included in the DO_INITCALLS () function.
5.init process and inittab boot command The init process is the starting point of all system processes. After completing the nuclear boot, the init program is loaded in this thread (process) space, and its process number is 1.
The init server needs to read the / etc / inittab file as its behavioral pointer, inittab is a descriptive (non-executable) text, each of which has the following format:
ID: Runlevel: Action: Process wherein the ID is an entry identifier, Runlevel is the run level, Action is an action code, and process is a specific executor.
ID generally requires 4 characters, for Getty or other login program item, requires the ID to be the same as TTY, otherwise the Getty program will not work properly.
Runlevel is an identifier of the run level of init, usually 0-6 and S or S. 0, 1, 6 running level by the system, 0 as a shutdown action, 1 as a restart to single user mode, 6 is the restart; S and S meaning, indicate single user mode, and no inittab file, therefore does not appear in inTtab In fact, when entering a single user mode, init is running / Sbin / Sulogin on the console (/ dev / console).
In the general system implementation, 2, 3, 4, 5 levels are used. In the redhat system, 2 indicates a multi-user mode supported by NFS, 3 indicates full multi-user mode (also the most common level), 4 Reserved to the user custom, 5 means the XDM graphic login method. The 7-9 level is also available, and the traditional UNIX system does not define these levels. Runlevel can be a plurality of values in parallel to match multiple run levels, for most Actions, only when RunLvel is successful when RunLvel is successful.
INitDefault is a special Action value for identifying the default start level; after init is activated by the core, it will read the initTDefault item in the initTab, and obtain the Runlevel and as the current run level. If there is no inittab file, or there is no initDefault item, init will request input Runlevel on the console. Sysinit, boot, bootwait, etc. Action will run unconditionally at the system start, and ignore the Runlevel, the rest of the Action (excluding INITDEFAULT) is related to a RunLvel. The definition of each Action has a detailed description in the inittab's Manbook.
In the Redhat system, in general, INITTAB will have the following:
ID: 3: INITDEFAULT:
# Represents the current default run level of 3 - complete multi-task mode;
Si :: sysinit: /etc/rc.d/rc.sysinit
# Automatically execute /etc/rc.d/rc.sysinit script when boot
L3: 3: Wait: /etc/rc.d/rc 3
# When the run level is 3, run the /etc/rc.d/rc script with 3 for the parameter, and init will wait for it.
0: 12345: Respawn: / sbin / mingetty TTY0
# In 1-5 levels, perform / sbin / mingetty programs in tty0 as parameters, open TTY0 terminals for
# 用户 用户 登, then run the mingetty program again if the process exits
x: 5: Respawn: / USR / BIN / X11 / XDM - NODAEMON
# Run the XDM program at level 5, provide the XDM graphical way login interface, and re-execute when exiting
Six.RC Start Script Added INIT Processing The initial RC script will introduce the specific work of the RC script.
In general, the RC startup script is located in the /etc/rc.d directory, the most common action in rc.sysinit is to activate the exchange partition, check the disk, load the hardware module, these actions, no matter which run level needs priority . Other boot or bootwait action will only be performed only when INIT is running only after rc.system.
If there is no other boot, bootwait action, under run level 3, / etc / rc.d / rc will be executed, the command line parameter is 3, that is, execute all the /etc/rc.d/rc3.d/ directory all file. The files under RC3.D are symbolic connections to each shell script in /etc/rc.d/init.d/ directory, and these scripts can generally accept parameters such as Start, STOP, Restart, Status. The RC script launches all START parameters that starts with S, before this, if the corresponding script also has a link to the K head, and it is already running state (with / VAR / LOCK / SUBSYS / down as a flag), The script begins starts first, stops these already started services as the parameters as the parameters, and then run again. Obviously, the direct purpose of this is that when INIT changes the run level, all related services will be restarted, even the same level.
After the RC program is executed, the system environment has been set, and the user logs in to the system.
Seven. Getty and Login are returned after RC, init will be controlled and launch MINGETTY (see Section 5). MINGETTY is a simplification of Getty and cannot handle serial operations. Getty features generally include:
Open the terminal line and set the mode output login interface and prompt. Accept the username as the parameter of the login, load the Login program default login prompt record in the / etc / Issue file, but start, general Both rc.local scripts are regenerated according to the system environment. Note: The prompt information for remote login is located in /etc/issue.net.
The login program runs in the same process space in Getty, accepting the username parameters sent by getty as the username of the login.
If the username is not root, and there is / etc / nologin file, login will output the contents of the NOLOGIN file, and then exit. This is often used to prevent non-root user logins when maintaining.
Only the terminals registered in / etc / securetty allow the root user to log in, if this file does not exist, root can log in on any terminal. The / etc / use of file is used to make additional access restrictions on the user. If this file does not exist, there is no other restriction.
When the user logs in to these checks, login searches for the / etc / passwd file (if necessary, search / etc / shadow file) is used to match the password, set the primary directory, and load the shell. If you do not specify a primary directory, it will default to the root directory; if you do not specify the shell, it will default to / bin / sh. Before the control is transferred to the Shell, getty will output the information of the last login system recorded in / var / log / lastlog, and then check if the user has new mail (/ usr / spool / mail / {username}). After setting up the UID, GID, and TERM, PATH and other environment variables, the process loads the shell, login is completed.
Eight. After the user login in the Bash Run Level 3, the shell specified by the user will start with / bin / bash as an example to continue our boot process.
Bash is the GNU extension of Bourne Shell, in addition to all features of SH, have also added a lot of features and functions. Bash started by login is started as a login shell, which inherits the Term, Path equivalent environment variables set by Getty, where Path is "/ bin: / usr / bin: / usr / loc), for normal users, for ordinary users Root is "/ sbin: / bin: / usr / sbin: / usr / bin". As a login shell, it will first look for the / etc / profile script file, and execute it; then if there is ~ / .bash_profile, execute it, otherwise it will be executed ~ / .bash_login, if the file does not exist, then execute ~ /. Profile file. Then Bash will execute ~ / .bashrc files as an interactive shell (if present), in many systems, ~ / .bashrc will start the / etc / bashrc as a profile within the system.
When the command line prompt is displayed, the entire startup process is over. At this time, the system runs the kernel, runs a few core threads, running the init process, runs a batch of daemons activated by the RC startup script (such as inetd et al.), Running a BASH as a user's command interpreter.
Attached: XDM mode login If the default run level is set to 5, there is no 1-6 Getty listening to the text terminal in the system, and there is a graphic login window that launches an XDM. The login process is similar to the text, but also provides username and password. The XDM profile defaults to / usr / x11r6 / lib / x11 / xdm / xdm-config file, which is specified / usr / x11r6 / lib / x11 / xdm / xsession as an XDM session description script. After the login is successful, XDM will execute this script to run a session manager, such as gnome-session. In addition to XDM, different window management systems (such as KDE and GNOME) provide an XDM alternative, such as GDM and KDM, and the functions of these programs are similar to XDM.
About the author Yangshazhou, male, now attracting a Ph.D. in the computer software of the National Defense University Computer College. You can contact him by email pubb@163.net.
