Boot-time Alternatives

In order to understand how Unslung frees up the memory, we must understand the basic boot-time architecture of the NSLU2. As we touched on in my last article, the first code to run when the box is powered on is the RedBoot boot loader. Among other things, the boot loader is responsible for copying the Linux kernel and ram disk from flash into RAM.

When the copying is complete, control is handed over to the Linux kernel. The kernel starts up and mounts the RAMdisk as the root or base filesystem. It then starts up the initialization processes from within that root filesystem. The initialization processes mount the hard drive and/or the flash drive and then continue on to the web server, the network file servers, etc. At this point the box is running and ready for use.

All of the basic functionality of the NSLU2 is contained in the RAMdisk because the box is designed to boot even if there's no hard drive attached. That's a nice feature, but if you think about it, it can be very wasteful. You may have a world of free space on your 250 Gigabyte hard drive, but you're stuck trying to squeeze all desired executables, libraries, html files, etc into the filesystem on a tiny RAMdisk.

What if you could put all of the files on the disk drive instead of the RAM drive? Then you'd be able to allocate a much larger filesystem and in the process, free up the memory that was previously allocated to the RAM drive. It would also be nice if you could be backward compatible with the Linksys boot sequence. If the drive had the filesystem on it, you'd use it. If a disk was not plugged in or if the disk didn't have a filesystem on it, you'd use the filesystem on the RAMdisk just like before. This is the approach taken in the Unslung firmware. Now let's explore how it's done.

Pick your Filesystem

It's common practice to build a Linux kernel with a pre-specified indicator of which drive to use for the root filesystem. This can be done either in the kernel itself or it can be passed to the kernel from the boot loader. In the case of the NSLU2, Linksys hard-coded the kernel, specifying that the root filesystem was a RAMdisk . That's all Linksys ever intended to use. But like most things in Linux, there's a method to avoid the use of hard-coded variables such as the root filesystem designator.

Linux has the capability to make a run-time determination of where the root filesystem is located. This capability is commonly used where a single kernel is built to run on varying hardware platforms. For example, the same kernel image can boot on a system where the root can either be found on an IDE drive or a SCSI drive. Before Linux chooses where to find the root, it pokes around and determines what drivers to load and where to find the root. When Linux figures it out, the proper root is mounted and the boot continues normally. This is the feature used in Unslung.

The Unslung code for root detection is not part of the kernel proper. Instead it's found in a Linux feature called the initrd, or initial ram disk. The initrd is a special temporary ram disk designed to hold user-code that's executed before the root filesystem is mounted. The Unslung developers first put a dummy root designator in the kernel and then added code to the initrd to check the hard drives for the real root filesystem. If one of the attached drives has a root filesystem, Linux is told to use it rather than fall back to the RAMdisk. Once Linux decides to use the hard drive for the root filesystem, the 10 MegaByte RAMdisk is freed up, and the RAM falls back into the free pool for other uses.

Tags: BYOD, Hacking, How To, Linksys, NAS, NSLU2,

Related Articles: