A few questions for you to think about which may affect your design choices:
If a task corrupts another task data, it is a bug and must be fixed.
Agreed. If this situation arose, how would you find out which of your tasks the bug is in?
We have about 30 tasks, handling GPIO, I2C, graphics, user input, network protocols, watchdog and ethernet.
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.
We keep code in userspace to avoid GPL.
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.
The whitepaper says redesign RTOS code, not port it. This is much work! We do not understand why redesign might be needed.
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?