To develop a network booting package suitable for embedding in *ROMs to download images to computers via network interfaces, in the first instance Linux, FreeBSD and Windows (95 and 98). This package shall have the following characteristics. Each requirement is annotated with the rationale in italics.
It shall be Open Source.
Open Source designates software for which the source is freely available for reuse. For the definition see here. This is an essential condition of funding, as the NLnet Foundation supports network software projects whose results must be open for reuse. Furthermore, as far as NILO is concerned, the process by which the software is developed is just as important as the result. The development model and timeline of NILO requires that end users of the software be involved in the refinement process, rather than being passive recipients of a package that is delivered by the implementor(s) at the end of the project.
It shall use existing Linux network drivers in source form. As far as possible it should use the drivers without any source modifications. If absolutely necessary automated modification (with configuration scripts) may be allowed. The choice of Linux drivers is because Linux has the widest range of network device support. It is only used in the boot *ROM and does not affect the type of images that can be loaded later or the networking software that is loaded.
Of the network drivers which are available as Open Source, Linux has the widest coverage of current hardware. Donald Becker asserts as of September 1998 that “Linux now supports almost every current-production PCI Fast and Gigabit Ethernet chip!” with a few exceptions. This is a good base to work from. It will allow NILO to track improvements in driver modules.
Why source form? Why not loadable modules? Object code modules are black boxes. In particular compilation options and versioning can introduce hassles. This hassle is unnecessary. Compiling device drivers from source is not rocket science if one has the development tools. Furthermore a network loader does not need the extra space overhead of a dynamic loader. For the same reasons and more, we reject drivers APIs such as ODI or NDIS. These modules are generally not available in source form. Multiple driverinterfaces will add to the cost of maintenance. Packet drivers are available in source form but they are real-mode drivers. They also don't work on non-Intel architectures.
Note that the unmodified source requirement only applies to the drivers themselves. It is perfectly ok and indeed necessary to change the include file environment and code NILO specific support routines.
It shall use BOOTP or DHCP as protocols for obtaining initial configuration information.
BOOTP and DHCP are the two commonly accepted Internet protocols for obtaining configuration information.
It shall be compliant with the Etherboot/Netboot tagged image format and the Intel PXE specifications. It shall have callback entry points for secondary boot loaders to request network services, so as to allow menus, etc to be implemented in secondary loaders.
The network boot image needs to be in some suitable format. Looking at the requirements for network booting, one sees that the tagged image format designed by Jamie Honan is close to, if not the minimal specification that satisfies the requirement of being able to deposit data at arbitrary locations in memory. There are some features that could have been improved but by and large, it's a good design. The Intel PXE specifications allow secondary loaders to use the bootp/DHCP and tftp services. Providing these callback points allows the initial image to be small and facilities such as menus and so forth to be implemented in secondary and subsequent loaders, instead of burdening NILO with such features. Note that a general network stack is not required, only support for bootp/DHCP and tftp. And ARP of course.
It shall initially run on x86 PCs where x >=3. It shall support both ISA and PCI network adapters. PCI adapters shall appear as PnP devices on the PCI bus.
x86 PCs are the most widely used platforms for the OS that are targetted. If NILO is well written, with a small amount of effort, it will be portable to other machine architectures with minimal effort especially as some of the Linux device drivers have proven to be multi-platform. 386s are the lowest platform of interest since they have 32-bit address capability and memory protection required to run the OSes of interest. 486s and above do not add significantly to the features already on 386s, while 286s and 086s are obsolete.
It is strongly desirable to have a footprint <= 32kB and preferably <= 16kB.
32 kB is estimated to be a reasonable target. Larger ROM slots are only found on newer NICs. The use of compression means that about 48kB is actually available for code. When one considers that Etherboot can fit a minimal boot ROM in 8kB and a feature-packed boot ROM in 16kB (including features that can be migrated to secondary boots in NILO), there should be enough room for accomodating a Linux driver plus support functions. Uninitialised data segments do not have to be allocated in the 48kB just below the 640kB boundary, but can be allocated from extended memory, since we can assume that we have a 386 or better, with memory mapping, and at least 4 MB of memory. In a previous version of the objectives, this requirement was stated perhaps too strictly. It is possible that some Linux driver will be too large to fit in 32kB. Therefore to avoid problems in the contractual sense, this requirement is loosened to only make it highly desirable that a NILO boot ROM fit in 32kB and chances are that most drivers will. Those that exceed this limit are probably complex hardware that have larger ROM slots anyway.
It shall be able to be hosted on any Un*x system supporting the GNU development tools.
The GNU development tools: compiler and associated utilities run on many platforms and are well supported. It also increases the chance that a driver can be compiled for a different machine architecture. Recent releases of gas support 16-bit real mode assembly code needed for some of the startup code.
If possible, shall use the virtual memory facilities of x86 PCs to protect NILO from inadvertent overwriting.
This is not a strong requirement, but it was noted that some programming and loading errors could be caught if the boot loader protected itself from overwriting. Since protected mode will be used on 386s and above, this may simply be a matter of assigning the appropriate access rights to the boot loader segment.
It shall be properly documented for both users and future developers.
Good documentation is essential if users are to adopt the package. The continued viability of NILO as Open Source depends strongly on good documentation for future implementors.