git.sur5r.net Git - bacula/rescue/blob - rescue/linux/cdrom/yaird-0.0.5/doc/spec.xml

   1 <section id="spec">
   2   <title>Goals, features, to do</title>
   3   <para>
   4     The purpose in life of a tool like <application>Yaird</application>
   5     is to produce an initial boot image that loads the required modules
   6     to allow a booting kernel to access the root file system and from
   7     there use the startup scripts to get to the default run level.
   8     This means that hardly any drivers need to be compiled into the kernel
   9     itself, so a distribution can produce a kernel with a large amount of
  10     modules that will run unchanged on practically any hardware, without
  11     introducing a large number of unused drivers that would waste RAM.
  12     In a sense, the initial boot image customises the kernel to the hardware
  13     it happens to be running on.
  14   </para>
  15
  16   <para>
  17     That purpose still leaves a lot of room to optimise for different
  18     goals: as an example, you could attempt to make the generated
  19     image as small as possible, or you could attempt to make the
  20     generated image so flexible that it will boot on any hardware.
  21     This chapter discusses the goals that determined the design, the
  22     resulting features, and what's still left to do.
  23   </para>
  24
  25   <para>
  26     The goals<footnote>
  27       <para>
  28         Well, not really.  I started this thingy to show off a small
  29         algorithm to find required modules based on sysfs information.
  30         To make that a credible demonstration, the small algorithm
  31         turned out to need a lot of scaffolding to turn it into a
  32         working program ...
  33       </para>
  34     </footnote>
  35     of <application>Yaird</application> are as follows:
  36     <itemizedlist>
  37
  38       <listitem>
  39         <para>
  40           Be free, as in GPL.
  41         </para>
  42       </listitem>
  43
  44       <listitem>
  45         <para>
  46           Be maintainable.  Small functions with documented arguments
  47           and result are better than a shell script full of constructs
  48           like <code>eval "awk | bash | tac 3>&amp;7"</code>.
  49         </para>
  50       </listitem>
  51
  52       <listitem>
  53         <para>
  54           Be secure and reliable.  The application should stop with an error
  55           message at the slightest provocation, rather than run the
  56           risk of producing a non-booting initrd image.
  57           The application should not open loopholes that allow the 'bad
  58           guys' to modify the image, gain access to raw devices or
  59           overwrite system files.
  60         </para>
  61       </listitem>
  62
  63       <listitem>
  64         <para>
  65           Be distribution agnostic.  Fedora and Debian run similar
  66           kernels and similar startup scripts, so there's little
  67           reason why the glue between the two levels should be
  68           completely different.
  69         </para>
  70       </listitem>
  71
  72       <listitem>
  73         <para>
  74           Have limited footprint.  The tools needed to build and run
  75           the application should be few and widely available, with a
  76           preference for tools that are installed anyway.
  77         </para>
  78       </listitem>
  79
  80       <listitem>
  81         <para>
  82           Be future proof.  Future kernels may use different modules
  83           and may change device numbers; the application should need
  84           no changes to cope with such migrations.
  85         </para>
  86       </listitem>
  87
  88       <listitem>
  89         <para>
  90           Promote code reuse.  Make functions side-effect free and
  91           independent of context, so that it's easy to package the
  92           core as a library that can be reused in other applications.
  93         </para>
  94       </listitem>
  95
  96       <listitem>
  97         <para>
  98           Generate small images.  The application should accurately
  99           detect what modules are needed to get the root file system
 100           running and include only those modules on the generated
 101           image.<footnote>
 102               <para>
 103                 An alternative and equally interesting exercise would be
 104                 an attempt to generate a universal initrd that could be
 105                 distributed together with the kernel.  Such an image
 106                 would most likely be based on udev/hotplug.
 107               </para>
 108             </footnote>
 109           </para>
 110         </listitem>
 111
 112     </itemizedlist>
 113   </para>
 114
 115   <para>
 116     Requirements:
 117     <itemizedlist>
 118
 119       <listitem>
 120         <para>
 121           Linux 2.6.8 or later, both when running
 122           <application>yaird</application> and when running the generated
 123           image.  By limiting the goal to support only recent kernels,
 124           we can drastically reduce the number of special cases and
 125           knowledge about modules in the application.
 126         </para>
 127       </listitem>
 128
 129       <listitem>
 130         <para>
 131           Sysfs and procfs, both on the old and on the
 132           new kernel.
 133         </para>
 134       </listitem>
 135
 136       <listitem>
 137         <para>
 138           Perl and the HTML-Template module.
 139         </para>
 140       </listitem>
 141
 142     </itemizedlist>
 143   </para>
 144
 145   <para>
 146     To achieve these goals, the following features are implemented:
 147     <itemizedlist>
 148
 149       <listitem>
 150         <para>
 151           Templating system to tune the generated image to a
 152           given distribution; templates for Debian and Fedora FC3
 153           included.
 154         </para>
 155       </listitem>
 156
 157       <listitem>
 158         <para>
 159           Interprets <filename>/etc/fstab</filename>, including
 160           details such as octal escapes, <code>ignore</code> and
 161           <code>noauto</code> keywords, and &mdash; for ext3 and reiser
 162           file systems &mdash; label and uuid detection.
 163           Where applicable, options in <filename>/etc/fstab</filename>
 164           are used in the generated image.
 165         </para>
 166       </listitem>
 167
 168       <listitem>
 169         <para>
 170           Supports volume management via LVM2; activates only the volume
 171           group required for the root file system.
 172         </para>
 173       </listitem>
 174
 175       <listitem>
 176         <para>
 177           Supports software RAID via mdadm; activates only required
 178           devices.
 179         </para>
 180       </listitem>
 181
 182       <listitem>
 183         <para>
 184           Understands SATA, IDE devices.
 185         </para>
 186       </listitem>
 187
 188       <listitem>
 189         <para>
 190           Generated image does not use hard coded device
 191           numbers.<footnote>
 192             <para>
 193               Except where the distribution depends on it;
 194               there are some issues with mdadm in Debian.
 195             </para>
 196           </footnote>
 197         </para>
 198       </listitem>
 199
 200       <listitem>
 201         <para>
 202           Image generation understands how included executables may
 203           depend on symbolic links and shared libraries.  Shared libraries
 204           work for both glibc and klibc.
 205         </para>
 206       </listitem>
 207
 208       <listitem>
 209         <para>
 210           Support input devices such as USB keyboard, if the input
 211           device supports sysfs.
 212           Input devices are needed in the initial image to supply
 213           a password for encrypted root disk and to do debugging.
 214         </para>
 215       </listitem>
 216
 217       <listitem>
 218         <para>
 219           Basic support for kernel command line as passed by the boot
 220           loader.  Interprets init=, ro, rw.
 221         </para>
 222       </listitem>
 223
 224       <listitem>
 225         <para>
 226           Interprets the blacklist information from hotplug.
 227         </para>
 228       </listitem>
 229
 230       <listitem>
 231         <para>
 232           Interprets the kernel configuration file that defines whether a
 233           component is built in, available as a module or unavailable.
 234           By maintaining a mapping between module name and config
 235           parameter for selected modules, we avoid error messages if
 236           for instance a required file system is built into the kernel.
 237         </para>
 238       </listitem>
 239
 240       <listitem>
 241         <para>
 242           Supports initramfs, both in Debian and Fedora versions.
 243           An example template using the older initrd model
 244           is included for Debian.
 245         </para>
 246       </listitem>
 247
 248       <listitem>
 249         <para>
 250           Does not require devfs in either the old or the new kernel.
 251         </para>
 252       </listitem>
 253
 254     </itemizedlist>
 255   </para>
 256
 257   <para>
 258     Obviously, this tool is far from complete.  Here's a list of
 259     features that still need to be implemented:
 260     <itemizedlist>
 261
 262       <listitem>
 263         <para>
 264           Understands USB and SCSI storage, no special provisions
 265           are needed for code generation, but it's not tested yet.
 266         </para>
 267       </listitem>
 268
 269       <listitem>
 270         <para>
 271           EVMS, an alternative user level interface to LVM2 and MD,
 272           is not supported yet.
 273         </para>
 274       </listitem>
 275
 276       <listitem>
 277         <para>
 278           Swsusp is not supported yet.
 279         </para>
 280       </listitem>
 281
 282       <listitem>
 283         <para>
 284           Module aliases and options as specified in
 285           <filename>/etc/modprobe.d</filename> are not supported yet.
 286         </para>
 287       </listitem>
 288
 289       <listitem>
 290         <para>
 291           Firewire and DASD are not supported.
 292         </para>
 293       </listitem>
 294
 295       <listitem>
 296         <para>
 297           NFS, loopback and encrypted file systems are not supported.
 298         </para>
 299       </listitem>
 300
 301       <listitem>
 302         <para>
 303           Configuration info is hard coded in a module; it should be
 304           possible to read this from a file.
 305         </para>
 306       </listitem>
 307
 308     </itemizedlist>
 309   </para>
 310
 311 </section>