katalix.com

Hi,

We are starting a project to port our existing RTOS (Vxworks) code to Embedded Linux. We will change RTOS tasks to threads in our Linux application. The whitepaper suggests that this would be a mistake. Why? This seems to be the obvious way to port Vxworks code to embedded Linux!

Thank you

Otto

An important question to consider when porting RTOS code to Linux is: Do these functions belong in the same memory space? In Linux the memory of a process is protected from accidental corruption by other processes, a feature not present in many RTOSes, and is a benefit of Linux which you will be missing out on if everything runs in the same process space.

If you port your all your RTOS tasks to POSIX threads running inside a single Linux process, you are coupling potentially unrelated functions. In an RTOS, where tasks are the primary multiprocessing mechanism this is not really a problem, but on Linux each thread belongs to a process. If you have all your tasks in one big process, you are unnecessarily coupling unrelated functionality.

Taking a Linux desktop system as an example, it would be strange to see the desktop windowing system and the webserver as threads within a single process. It is clear that their functionality does not belong together, and you would be annoyed if a bug in the webserver could bring down the windowing system. Applying this to an embedded system, does the watchdog task belong in the same memory space as the core application?

Have you considered how drivers in your current RTOS environment will port to Linux? Do you, for example have a situation where application tasks interact directly with driver tasks? Remember that these will need to be changed to work within the confines of the Linux userspace / kernel interface. Linux drivers do not usually make use of kernel threads unless there is a very good reason to do so.

A Large single process will generate large core files when it crashes. Changing and recompiling a small element of a single process application takes longer than recompiling just one out of a collection of smaller applicatons.

Just a brain dump of some issues I could think of, I'm sure there are more...

Cheers,

Chris.

Hi Chris,

Thank you for these informations.

We do not use Vxworks virtual memory RTP add-in so all our tasks run in the same address space. If a task corrupts another task data, it is a bug and must be fixed. OS protection is not needed. We have about 30 tasks, handling GPIO, I2C, graphics, user input, network protocols, watchdog and ethernet. We move ethernet to Linux kernel and run other tasks in Linux threads using a Vxworks to Linux porting kit from the internet. We keep code in userspace to avoid GPL.

The whitepaper says redesign RTOS code, not port it. This is much work! We do not understand why redesign might be needed.

Thank you
Otto

Otto,

A few questions for you to think about which may affect your design choices:



Agreed. If this situation arose, how would you find out which of your tasks the bug is in?



What mechanism do you intend to use to be informed of and process any hardware interrupts for any of these tasks which use them?

Do any of the devices serviced by your drivers have firm real-time servicing requirements?

Do any of the devices you have drivers for already have published GPL'd in-kernel equivalents which you could use or extend?

In order to guarantee prompt interrupt servicing it is better to have interrupt processing inside the kernel where it belongs.



There are already Linux subsystems (although perhaps not for the specific chips) for all of the drivers you mention, which are already under the GPL. What is the reason for keeping your RTOS versions, familiarity with the code? If someone offered you a free choice of two drivers you hadn't written - one designed from the ground up for the target OS, or one designed for a different OS running via a compatibility layer - which would you choose? Consider that adapting the code already in Linux will lead to drivers which are better integrated and will run faster.

As an example, if I have my own framebuffer driver and I port it to Linux via an RTOS shim, how will I test it, what libraries will I sit on top of it? If I instead rewrite a driver to the standard Linux framebuffer subsystem, I can make use of existing libraries and applications, such as directfb (http://directfb.org/) or QT widgets (http://www.trolltech.com/products/qt/) - which both sit on top of the Linux framebuffer. Yes, you may have to 'give away' a small amount of your low-level device-specific code under the GPL - but in exchange you recieve a much larger amount of well-tested, widely deployed, useful code.

I would suggest that if your company is intending to produce further Linux based products, then the time spent understanding the existing Linux drivers and subsystems, and porting your existing drivers to match will pay off.



It may be less work to redesign the code for the target environment than it will be to debug the problems which arise from trying to make the new environment look like the old one. For example, the timings of your application will definitely change, are you 100% certain that your tasks will operate in the same way if you change the order in which events happen?