Processo de Startup do Linux
•Descargar como ODP, PDF•
2 recomendaciones•796 vistas
Palestra: Processo de Startup do Linux - Prof. Mauro Tapajós Santos
![Objetivos ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Processo de Startup do Linux
Similar a Processo de Startup do Linux (20)
Más de Mauro Tapajós
Más de Mauro Tapajós (20)
Processo de Startup do Linux
- 1. Startup do Kernel do Linux Prof. Mauro Tapajós
- 3. Levantar as questões relevantes sobre o assunto para a pesquisa em andamento do projeto
- 4. Investigar as dúvidas que ocorrerem aos participantes e esclarecê-las para que a pesquisa siga adiante
- 7. Sonda o barramento para descobrir o dispositivo bootável
- 9. O primeiro setor da mídia de boot é carregado em memória e executado
- 10. Este pequeno programa é responsável em carregar o SO. Aqui podem existir boot managers como o LILO (/etc/lilo.conf) ou o GRUB
- 12. Normalmente carregado em dois estágios
- 13. Requer suporte firmware (“ hardware bootstrap ”) cpu firmware (PROM) kernel primary secondary memory primary secondary kernel net floppy cd-rom boot device? bootloader
- 15. Geração de INT 19h (bootstrap)
- 16. Seleção do boot device
- 20. Definir parâmetros de boot
- 22. Não tem conhecimento prévio da estrutura de filesystem
- 23. Para encontrar os kernels tem que fazer uma “mapa” (block map) – arquivo /boot/map
- 24. /boot/boot.b é parte do loader (não sei se é a secundária do LILO ou a primária)
- 25. Exemplo: LILO /sbin/lilo (“map installer”) /etc/lilo.conf /boot/boot.b /boot/chain.b /boot/map /boot/vmlinuz
- 27. Como ele normalmente está comprimido, um pequeno código de descompressão é embutido no início da imagem do kernel para descomprimi-lo
- 28. O kernel então analisa o hardware e tenta configurá-lo carregando os drivers adequados
- 29. Depois ele tenta montar o filesystem root (/) – normalmente em modo read-only
- 30. Com o filesystem montado, ele roda o programa init (/sbin/init) que será o processo de número 1 e irá carregar os serviços configurados no sistema
- 31. O sistema então vem para o runlevel single-user e/ou multi-user
- 32. Startup do Kernel Linux
- 34. Ao ser carregado, ele indica quanta memória ainda está disponível
- 35. O primeiro código do kernel a ser rodado é o startup_32: (label Assembler) que chama a função start_kernel() Power on Power off Boot Kernel Init OS Init RUN! Shut down
- 37. trap_init - ?
- 38. init_IRQ – Inicializaçào das rotinas de manipulação de IRQs
- 39. sched_init – Inicialização do scheduler de processos
- 40. softirq_init - Inicializaçào das rotinas de manipulação de interrupções de software
- 41. time_init - ?
- 42. console_init - ?
- 43. init_modules - Inicialização dos módulos (se houverem)
- 44. kmem_cache_init – caches de memória
- 45. Sti - ?
- 47. mem_init - ?
- 50. fork_init – Suporte a forks
- 52. vfs_caches_init – cache de VFS
- 53. buffer_init - ?
- 55. signals_init – Manipulação de sinais
- 56. proc_root_init – fs /proc
- 57. ipc_init – comunicação interprocesso
- 58. check_bugs - ?
- 59. smp_init – Suporte multiprocessamento?
- 60. rest_init – Dispara a thread init, destrava kernel e roda loop de execuçào infinito cpu_idle
- 63. sysctl_init
- 64. pci_init
- 65. sock_init
- 68. free_initmem
- 69. unlock_kernel
- 70. execve
Notas del editor
- Firmware usually has provisions for loading some fixed, small amount of code. In the Intel world, that’s a 512 byte “boot sector”. Even the Linux hackers can’t fit an operating system into 512 bytes! The game is to load a series of increasingly larger and more capable code segments. The two-stage process seems sufficient, in theory. The first fixed-length piece of code loads a larger, arbitrary length code segment. Due to other constraints, it is often convenient to “bootstrap” a more capable loader which can then load the final target (or another, more capable loader). By “hardware bootstrap” I mean the mechanism that loads the first bit of code, the primary. Some authors just use the term “bootstrap”. Even if the firmware can boot your kernel directly, it is convenient to interpose a software loader for additional flexibility. Updating firmware is not easy when you need to do something slightly differently. Updating a software loader is much easier.
- When you power-on the Intel, it reads a “start address” from location 0xfffffff0 and jumps to that location. In the standard PC configuration, this address is the BIOS entry point. Strangely, the location 0xfffffff0 is also part of BIOS (the high 64K of memory). This indirect mechanism allows Intel chips to be used in non-PC settings. Everything happens in real-mode so some memory mapping tricks are used to make the high BIOS addresses reachable in real-mode. After executing the POST, BIOS enters the bootstrap interrupt handler and tries to load a boot sector using the BIOS-defined order. For a floppy, BIOS always loads the first sector. For a hard disk, the first sector which is a Master Boot Record (MBR or mboot) containing some code and a partition table are loaded. The loaded code searches the partition table for the active (bootable) partition. If the MBR is from the active partition we are done. If the active partition is some other partition, the MBR code loads the boot sector of that partition. This is sometimes referred to as a partition boot sector or pboot. There are further complications for extended and logical partitions. Eventually the “correct” boot sector is loaded. Each boot sector contains a “magic number” to verify that it is, indeed, a boot sector. If the magic number is verified, then the boot sector code is executed.
- The “map installer” is controlled by the text file lilo.conf which identifies the desired boot scenario and details available boot images. Rerun /sbin/lilo anytime boot-related files change! That includes lilo.conf, the kernel itself, the boot loaders, the disk partition structure, etc. Newer versions of LILO keep most files in /boot by default. Under RedHat 6.1 the compressed kernel image is called vmlinuz. The actual primary and secondary bootloaders (the “real” LILO) live in the file /boot/boot.b. You can generate your own if you are clever enough but most people use the supplied loaders. Certain boot scenarios require loading additional loaders (for example, to boot off a logical partition). LILO supports this via the concept of a “chain loader”. The default chain loader is available as /boot/chain.b. The file /boot/map contains the actual sector map with a variety of other information. See the Technical Overview for details. Finally, the /boot directory may also contain an initial ramdisk image (initrd) used during boot.