5 Must-Ask Questions for Estimating a Linux Embedded Project

Estimation is one of the most important stages in the project lifecycle, especially when it comes to Linux embedded estimation. Whether you need to make a test stand for a larger project or build a custom-made software from scratch for a production device, it’s crucial to know what development-specific problems you may face in the process.

So, how to estimate your Linux embedded project properly? Since there are just too many factors to take into account, deciding what to focus on may be difficult for project stakeholders. Here are the five questions that would be good to ask before your team starts working on a new Linux embedded system project:

1. Will you work in the user space or in the kernel?
2. Do you need to write a prototype on this stage of the project?
3. Can you borrow any code from open sources?
4. What types of kernels and devices should be supported by the final solution?
5. Are there any critical development processes that project stakeholders are unaware of?

These questions highlight the factors that can affect the final estimation significantly. With the answers to them, you can predict possible problems and calculate the approximate time needed to fix them. So let’s look closer at each of these questions.

Will you work in the user space or in the kernel?

One of the first questions you should ask when estimating your Linux embedded project is whether you’re going to solve tasks in the kernel or in the user space. Depending on your choice, you can plan the embedded Linux development process more thoroughly and better specify time estimations for your project.

Generally speaking, it’s preferable to solve tasks in the user space whenever it’s possible. User-space programming brings fewer development risks and has a number of advantages, including but not limited to:

• Swappable memory;
• Easier debugging (compared to kernel debugging);
• The fact that user-space drivers can be killed without the risk to crash the entire system.

But most importantly, in the user space, a crashed code will almost never deadlock the entire system, unless there’s something really wrong with the hardware.

In the kernel, a misbehaving driver puts the entire system in danger of being crashed. However, there are cases when doing it in the kernel might be the only option on the table.

Do you need to write a prototype on this stage of the project?

The next important decision is whether or not you should write a sample prototype for your project. Creating a Proof of Сoncept (POC) takes a lot of time and you need to be 100 percent sure that these time spendings are well-founded.

Your Linux embedded development project may be needed for a test stand created at the start of a larger project. The problem is that developers can’t be sure what motherboard will be used in the final project, so creating a successful POC is a bit of a challenge and may become just a waste of project time.

Can you borrow any code from open sources?

Knowing the answer to the previous questions, you can see if there’s any ready code that your project can reuse in some way.

In the case of user-space programming, borrowing a piece of code is a common practice. By reusing the open-source code, you can significantly speed up the development process. There are several open-source frameworks that you can use for your Linux embedded projects, including Yocto and Buildroot.

When you solve tasks in the kernel, however, reusing someone else’ code is usually out of the discussion. Plus, if you’re required to use specific hardware, make sure to check if there are fitting drivers, emulators, and communication interfaces for the needed motherboard models.

For instance, if there’s no ready driver for a specific motherboard required by your project, you’ll need to build a custom driver from scratch. Developing, testing, and debugging this driver will take some time that you must take into account when estimating the project.

In order to test the built driver, it’s better to use a virtual machine (unless you’re not afraid to spend your weekend re-configuring the crashed system from scratch). However, here you may face one more challenge — the need to find a fitting emulator for your specific motherboard.

What types of kernels and devices should be supported by the final solution?

One more thing to clarify is the full list of kernels and devices that should be supported by the developed Linux embedded system. It’s better to make this list first thing when starting the project, so you will know what to focus on later.

Make sure to discuss all possible options of supported kernels and devices, as it may affect the duration of the development process significantly. For instance, if there are no fitting drivers for a set of required motherboards, the time needed for their developments and testing must be included in the general Linux embedded estimation.

Make sure to specify not only major releases but also the minor kernel versions that should be supported by your embedded solution. Remember that even switching between minor kernel versions may lead to a significant (and sometimes catastrophic) time overage.

Are there any critical development processes that project stakeholders are unaware of?

Finally, when estimating the total cost of a Linux distribution, don’t forget to consult Linux development experts to see if there are any little-known (but essential) processes left unaccounted. Think about any little-known tasks that may result in serious time overages.

Say, you plan to solve tasks directly in the kernel but there are no fitting drivers for your motherboard. Make sure everyone involved in estimating your project understands that building and debugging a custom driver in this situation will differ from writing a sample code in the user space.

Another thing to think of is whether you need to make a board support package (BSP). If yes, then you should specify the content of such a BSP at the beginning of the project.

Conclusion

Embedded Linux project estimation is a complex business-critical task. It’s important to take into account all kinds of pitfalls and possible issues that a developer may face while working on this project. Otherwise, releasing the final product in time won’t be possible.

In this article, we listed the five essential questions that any team should discuss before estimating a new Linux embedded system project. Hopefully, these questions will help you both ease the estimation process and plan your projects more thoroughly.

5 Must-Ask Questions for Estimating a Linux Embedded Project was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.