Building a Next-Generation Residential Gateway
Before embedded Linux became the de facto standard for networking devices, building a residential gateway (RG) or similar appliance used to be an expensive and nontrivial task. Real-time operating systems (RTOSes) used on these kinds of devices, such as VxWorks or pSOS, are relatively expensive and lack many features needed for an RG, which has to be purchased separately. VxWorks 5.5, for example, comes with a TCP/IP stack that has performance problems and does not even implement an L2 bridge, not to mention a firewall. This situation created a business opportunity for a number of companies, such as Ashley Laurent and Jungo, who sell RG software stacks for various OSes. The advent of embedded Linux distributions, such as uClinux, reduced the process of building an RG to choosing the right hardware, writing the drivers for peripherals and adding some kind of Web-based configuration utility. Embedded Linux reduced the development and cost of RG devices not only by providing many important features that either were missing or expensive in RTOSes, but also by easing the integration and debugging of drivers and applications, thanks to the clear POSIX driver model and kernel/user-mode separation.
However, Linux dominance in the embedded networking market is now challenged by new technologies. In the past, RG devices with ADSL, DOCSIS and 802.11 peripherals rarely were required to pass throughput beyond 10Mbps. New technologies, such as 802.11n and PON, make 100Mbps throughput a reality, challenging embedded engineers with the task of creating RGs capable of handling much higher traffic on the same or at least similarly priced hardware.
Before designing your own residential gateway, it may be worth taking a closer look at one of these devices.
If you decide to take a look inside your 802.11 access point or ADSL gateway, which probably will void your warranty, you will find an embedded board with a CPU (probably some MIPS variant), Ethernet switch, ADSL/DOCSIS and 802.11 chips, as illustrated in Figure 1.
Some (or even all) of the above can be integrated into one piece of silicon to form a System-on-Chip (SoC). On the other hand, you also may find the same stock mini-PCI (mPCI) 802.11 card connected to an embedded board as the one you will find in your laptop.
Chances are, your home gateway runs Linux. If you'd like to know for sure or maybe hack a bit on it, you have to solder the UART connector, which is relatively easy (most boards come with UART enabled, but without a connector). The software stack usually includes some version of Linux (2.4.x kernels are still pretty common in the embedded world), the usual user-space utilities and libraries, peripheral drivers and a configuration utility—either command-line interface (CLI), Web or both, as shown in Figure 2.
Now that you have a general picture of what makes a residential gateway, and assuming you have working hardware (more details on hardware later in this article), let's see what pieces of software you'll need. At the bare minimum, you need kernel sources, some variant of the libc library, basic user-mode utilities (at least a shell) and a cross-compiler toolchain to build them all. In short, you need an embedded Linux distribution. uClinux is a good choice, as it supports a wide range of CPUs (not necessarily CPUs without MMU, as the name might imply), comes with many useful user-mode utilities and has an easy-to-use kernel-style configuration system for all the packages. As always, the choice is not limited only to one distribution. There are a variety of free and commercial Linux distributions from which to choose.
Assuming your board (not just the CPU) is supported by uClinux, the process of building a working image boils down to downloading the distribution itself and the cross-compiler toolchain for your CPU and then simply following the build instructions. If your board is not supported by uClinux, chances are the board manufacturer will provide a board support package (BSP)—that is, adapt uClinux (or some other Linux version) to that hardware. If this is not the case, you have to write the BSP yourself, which is beyond the scope of this article.
The major components of the uClinux distribution are, of course, the kernel itself, the uClibc library and BusyBox. The uClinux kernel has support for MMU-less CPUs, but this feature is of minor importance nowadays. Because the cost of adding the MMU is so small, I expect that most, if not all, embedded CPUs used on an RG will have it. Nevertheless, uClinux is a great distribution, even if you don't exploit the MMU-less CPU support. The same goes for uClibc. It originally was created to support MMU-less systems, which, for instance, cannot have a fork(2) system call. But, even if you don't need this functionality, it is a great alternative for glibc on embedded systems, as glibc has much larger RAM requirements. BusyBox is a collection of standard UNIX utilities, optimized for embedded systems with low RAM. It comes with uClinux, and as with uClibc, you usually will prefer it over full-featured standard utilities, unless you have a system with enough RAM (typically above 16MB).
You need two important pieces of software that are not a part of uClinux. The first piece is a bootloader, which is software that usually resides in ROM (at least partially) and is responsible for loading the Linux image from Flash to RAM and performing some hardware initializations. Unfortunately, there is no standard bootloader for uClinux. In fact, there are no standards for bootloaders in the embedded world, and you cannot use PC bootloaders, such as GRUB or LILO. Your hardware manufacturer almost certainly will provide a bootloader, and I strongly suggest using it. If it does not support Linux, it usually is easier to adopt it than to port a different bootloader to your hardware. If you still choose to port the bootloader, Das U-Boot is a good choice, as are many others.
The second missing piece is a Web-based graphical user interface (GUI), which most users come to expect from RGs. Most, if not all, currently available RGs have a Web interface written from scratch. However, it does not have to be like this anymore with the introduction of the X-Wrt Project, one of the components of the OpenWrt Project, which you almost certainly will want to look at if you are building an RG. OpenWrt is a Linux distribution for the Linksys WRT routers (and not only those).
Add to this a bit of init script writing, and you are done, except for the peripheral (802.11, ADSL and so on) drivers, which is a topic for a another article.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide