katalix.com

Hello,

I manage a software support team for a European CPU board manufacturer. Our customers use RTOS and Linux. Our support costs have increased by 5 times since 2 years ago adding Embedded Linux for our boards.

What is best practise in this area?

Hello Hans,

Do you provide your customers with RTOS BSPs and/or Linux kernels? For Linux, do you provide kernel patches or complete Linux source trees? If you don't do so already, consider supplying your customers with kernel patches for each board and work towards submitting patches to the Linux kernel developers.

When submitting kernel patches, don't underestimate the time required to prepare patches and respond to review comments. Make sure that your code conforms to Linux coding style before submitting it. It is best to submit code as a series of patches to make it easier for reviewers. The article at http://lwn.net/Articles/160191/ provides good guidelines on patch submission.

When working with patches, you might find the quilt tool useful. This tool helps create and regenerate a series of patches. See http://savannah.nongnu.org/projects/quilt.

Hope I helped!

We provide some Linux drivers to our customers as binary kernel modules. The code comes from the manufacturer of one of the devices on our boards. It is not GPL so we cannot release kernel patches.

What is best practise for binary kernel modules?

Thankyou
Hans

Avoid them. There is no substitute for being able to see the code.

Having to build kernel modules for each and every kernel configuration that your customers use is going to cost you a lot of time and money. Discuss the problem with the device manufacturer - they might not be aware of the problems that this is causing you. They probably think they've done you a big favour by providing software for their device... Do they provide documentation with which you could write a new Open Source driver to avoid the binary modules? (Some don't.)

For next generation hardware, evaluate alternative devices which do not require you to ship binary kernel modules with your boards. If your company supplies a number of different boards, consider developing one with Open Source markets in mind (i.e. no binary kernel modules) and submit patches to the kernel lists for the board. This will give you a good indicator of how much your support overhead might reduce, allowing you to make the tradeoff between sticking with your current supplier or using an alternative device.

If you're stuck with the device for the forseeable future, consider partnering with one or more Embedded Linux distros. That way, you reduce the number of kernels that you have to support. However, this would of course reduce your potential customer base. For a generic CPU board, customers often have their own preference for which distro (or home grown variant) they want to use. It all depends on who your customers are.

The bottom line is that the cost of a device is made up of software costs as well as the cost of the hardware device itself.

The device comes with C functions for building the driver. No device document for register definitions to allow us to write our own driver!

I will speak to engineering about your suggestion.

I agree! Thankyou for your advise!

Hans