|Line 35:||Line 35:|
Revision as of 09:55, 4 April 2012
anaconda 代码量非常庞大，第一次阅读时您可能会觉得代码量有点多得吓人。当您想跟踪代码分析问题时，您会有无从下手的感觉。 这篇文章从非常高的角度对代码文件进行了分组，并且描述了各个代码文件的作用。本文对代码的分析并不详细，而且个别文件没有进行分组。一些功能的代码还可能分散在多个文件中。
这些文件提供了用户接口功能。anaconda 提供了三种方式的接口：图形安装方式、文本安装方式和命令行安装方式。每种用户接口的代码分别包含在一个 pythoon 文件中，该文件包含了实现这种安装方式中各个界面的类，以及其他的类。
pyanaconda/iw/ 目录包含图形安装方式中绘制各个安装界面的 python 文件。pyanaconda/textw/ 目录包含文件安装方式中绘制各个安装界面的 python 文件。data/ui/ 目录包含了图形安装方式中使用的 glade 接口文件。通常情况下，我们试图尽量减少 pyanaconda/iw/ 中的代码量，而是用 glade 文件描述图形安装方式中的各个界面。
如果安装过程中需要使用 VNC，这个文件包含 VNC 的创建过程，然后就可以才有你该图形界面方式安装系统了。
这些文件负责 anaconda 支持的各种高级存储方式的探测、配置、开启以及停止过程。 既可以处理硬件设备(FCOE、iSCSI、RAID、ZFCP 等等)也可以处理软件设备(encryption、lvm 等等)。目前，LVM 和 RAID 的使用率大大提高了，而其他方式则不常用了。
These files handle writing some sort of filesystem or filesystem-like abstraction to a storage device. Think of this as a layer on top of something in pyanaconda/storage/devicelibs/. Filesystem-like abstractions include disk labels, encryption, machine-specific boot partitions, and swap.
This file contains methods that are used for error checking, input validation, and displaying error messages. The graphical and text interfaces make use of it.
These files form a support library within the storage module, taking care of a variety of small tasks that don't fit well in another group. For the most part, the names describe what they do. pyanaconda/storage/__init__.py handles a rather large number of catch-all tasks including reading and writing storage-related configuration files, probing for existing installations, coordinating storage actions, marshalling data between storage objects, and performing sanity checks.
This group of files implements the partitioning logic. It holds the DeviceTree abstraction that stores existing partitions and requests in a meaningful way, defines the actions needed to write storage requests to disk, handles automatic partitioning (which is the default), and knows how to grow and shrink all requests until they fit in the space provided. Partitions themselves are created on disk by using the pyparted package.
These files control writing out the bootloader to the installed system. Each type of machine has its own bootloader quirks, and therefore has its own file in the booty/ module. bootloader.py ties it all together. This is useful both for fresh installations as well as upgrades.
These files hold the configuration settings that are either entered through the interface or through kickstart. To some extent they affect the installation (for instance, the language and keyboard settings are used in anaconda). However, the main purpose is to write these out to the installed system at the end of installation.
These files control package installation. anaconda allows for multiple package installation backends, though the only real one in the tree uses yum. Each backend provides methods for selecting groups and packages, removing groups and packages, writing out configuration settings, and so forth.
Installation classes define settings that form a sort of installation profile. This includes steps to show and skip, product names, installation method, enabled repositories, configuration settings, and so forth. We primarily use it to create a difference between Fedora and RHEL installs. Other projects or ISVs could define their own installation classes for their own defaults.
Kickstart is a way of automating installations by providing anaconda with a file that contains all the data that the user would have to provide via the UI. This file is an interface between the parser in the pykickstart package and the anaconda internals. It primarily provides a way of saving the settings in the places anaconda expects.
These files implement installation from the live CD. They provide a special installation method, a special package installation backend, and some files needed to launch the installer from the live CD's desktop.
These files provide methods specific to rescue mode and upgrades.
These files provide a variety of miscellaneous methods that are used throughout the installer. These functions include the logging framework, hardware probing via a udev interface, process control, handling exceptions, and other tasks. They also contain methods that just don't fit anywhere else.
This is the main anaconda program that gets called from the loader. It handles lots of environment setup, enables updates if they exist, reads any kickstart file, sets up VNC, and other tasks. When all this is done, it hands control over to the dispatcher which deals with the rest of the installation process.
These directories contain code that controls how the installation environment is made. This includes creating the initial ramdisk and the stage2 images, adding very basic versions of certain needed commands, splitting the installation tree into media-sized chunks, and other miscellaneous tasks.