The point of these questions is both to assess whether the product offered by the vendor is good enough for the project and to see how committed the vendor is to creating providing a complete solution that will be supported throughout the project:
• What devices does the kernel support? You'd think that the devices on the board would be supported, but that isn't always the case! Make a checklist of the devices that will be on the production board so you don't forget any when querying the board vendor. Some board vendors support the most commonly used devices, like network or serial ports, but don't have proper support for a video-out port or audio device.
• Where are the source code and patches for the kernel? Open source means you're entitled to the source code, any patches, and instructions explaining how to use those patches. Patches sometimes need to be applied in a certain order, because one patch makes changes on the assumption that some other patch has been applied first. The fact that patches are interrelated isn't indicative of poor engineering, but rather that the company has been carefully tracking the changes it makes to the main kernel. If you're aware of other patches that need to be applied, you should test to be sure they're compatible with what the vendor has supplied. For example, the patches for a project like Linux-tiny may make changes throughout the kernel, and those changes may collide with other changes from the vendor. Not all of these issues can be identified or solved before purchasing, but you should address as many that are known.
• How compatible are patches with the current Linux kernel? This is important. In the Linux project, changes happen to the head of line (old-school speak for the version that will be released next) and are rarely back ported. That means if there's a change to the kernel—say, to address a security issue—that change is made to the current kernel and not to the one included with the board, unless that kernel happens to be the head of line. The answer to this question is a function of how old the patches are in combination with how many other changes they contain. For some boards, the changes, although extensive, are limited to the parts of the kernel that deal specifically with the hardware and can be transferred easily to a newer version of the kernel if necessary. Even if patches can't be applied to the newest kernel, you many never need to switch to a newer kernel, making this a moot point.
• What level of testing has been performed? One of the things a commercial vendor knows is the state of the software being delivered. Sometimes, the answer is that no testing has occurred. Depending on the project, that may or may not be sufficient. The internal testing done by your company may trump what ever testing the board vendor has or hasn't done.
• Where's the toolchain? Getting the sources with the binaries is part of the GPL. There's no provision to ensure that the tools and software necessary to transform those sources into binaries are part of that equation. The toolchain supplied should be the same one used to build the kernel and the root file system (see the next item), and the supplier should include instructions on how to rebuild the toolchain as well.
The GNU toolchain is a group of related projects: a compiler, libraries, linker, utilities, and a debugger. The vendor should understand this notion and be able to describe the version and patches applied to each. As a user, the chances of rebuilding the toolchain completely are fairly low, but you're likely to need to add libraries or use a newer version of the debugger. Knowing how the toolchain is configured helps you determine compatibility with any additional or updated software. In addition, getting the answer to this question serves as a way to gauge the competency and level of engagement of the vendor with respect to their Linux efforts. Some board vendors put a great deal of care and effort into supplying a top-notch distribution, whereas others do the minimum to claim Linux support.
• What's in the root file system? This is a deliberately broad question, mostly because it's a broad topic. A root file system is a complex project that involves several related projects coming together. A root file system can be anything from one file to the contents of an enterprise Linux server. The vendor should be able to describe the version for each software component used in the root file system. If you plan to use shared libraries, make sure the shared libraries in the root file system match those in the toolchain. This is a critical detail! When you're crosscompiling applications that use shared libraries on the desktop, those binaries dynamically link to the shared libraries with the toolchain; however, when those same binaries are put in the root file system on the board, they attempt to link with those shared libraries. If there's a mismatch between the libraries used for the compilation and those used for execution, the software may refuse to load or, even worse, may fail unpredictably. If you're linking statically, the shared libraries aren't important, because the code that would reside in the shared library is included in the compiled binary.
• Do the devices supported on the board have their complementary userland supporting packages? This is another semi-trick question to gauge the level of care that went into creating the root file system. Devices have become more complex and, for lack of a better word, interactive. For example, supporting USB devices requires support in the kernel and complementary packages in the root file system. The Linux USB software stack includes programs in the root file system that are executed when a user plugs in or unplugs a USB device.
• Where are the root file system sources and patches, and how do I build it? Like the toolchain, the root file system is a confederation of packages that work together. Packages included in the root file system are typically licensed under the GPL, so you're due the source under that license agreement along with the build instructions. The build instructions need to explain how to apply any patches along with the information necessary for compilation. Because the root file system is a collection of packages, the vendor should explain how to assemble all the packages into something that you can use for booting the board. (This isn't part of the GPL, but it's knowledge you're paying for as part of the purchase.)
• How often does the company plan to upgrade the kernel? The Linux project (both the kernel and the collection of projects that make up the root file system) doesn't rest: changes are continually occurring, and that's certainly a good thing. As a customer, understanding how the board vendor reacts to this change helps you understand how you'll be kept up-to-date with the changes in the open source community. Will the software be updated as kernel and package updates occur? Is there a regular release cycle during which the vendor collects changes and validates and tests them before release? Or is the Linux distribution a snap-shot of the current state of the projects and never updated, leaving updates to you? All of these are valid approaches, and as the buyer, it's important for you to know what the board vendor is supplying.
• What support do you provide? What sort of questions will you answer? The answer to these questions reveals the amount of in-house expertise the vendor has at its disposal; in general, the more resources the vendor has, the more they're willing to share those resources with their customers. You should also ask yourself what level of support required. If this is the first embedded Linux project undertaken at your company, the type and level of support required will be different than if the company already has a high degree of Linux expertise. Some support agreements explicitly say that consulting services aren't offered, where consulting means providing advice related to how to use the software. From the vendor's perspective, the support contract exists to limit the support offered, so the vendor doesn't make a commitment it can't fulfill.
After signing the check and taking delivery of a Linux distribution included with the board, it's important to assess what was delivered. Plan to spend at least a working week to do the following:
1. Build the kernel.
2. Build the root file system.
3. Boot the board with the newly built root file system and kernel.
4. Compile and debug a small application on the board.
The first three tasks on the list should be done with the tools and advice offered by the vendor. The goal of this exercise is to immediately perform the tasks that will eventually happen in the project, to validate the quality of the delivered software. Even though the distribution includes a kernel that's ready to boot for the board, rebuilding a kernel or re-creating the root file system shouldn't be tasks you approach with trepidation, but rather as a natural part of the project. At a minimum, if the binaries (kernel and root file system) delivered by the vendor can't be reproduced, the distribution is defective and should be returned for a refund. Likewise, if you can't build and debug a small application, the vendor hasn't supplied you with a set of tools adequate for a project.
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Alan M. Conway at 01232010
1. Why is Linux such an incredible piece of sowtware
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.