Porting RTOS Device Drivers to Embedded Linux

As indicated above, porting character and block device drivers to Linux
is a straightforward if time-consuming activity. Porting network drivers,
though, can seem much more daunting.

Remember that while Linux grew up with TCP/IP, most RTOSes had
networking grafted onto them in the late 1990s. As such, legacy
networking often only presents bare-bones capabilities, such as being able
to handle only a single session or instance on a single port or to
support only a physical interface on a single network medium. In some
cases,
networking architecture was generalized after the fact, as with Wind
River VxWorks MUX code to allow for multiple interfaces and types of
physical connection.

The bad news is that you likely have to rewrite most or all of your
existing network interfaces. The good news is that re-partitioning for
Linux is not hard and you have dozens of open-source
network device driver examples to choose from.

Your porting task is to populate the areas at the bottom of
Figure 4 with suitable packet formatting and interface code.

Figure 4. Block Diagram of Linux Network Drivers

Writing network drivers is not for beginners. Because, however, many RTOS
network drivers actually were derived from existing GPL Linux
interfaces, you might find the process facilitated by the code itself.
Moreover, there is a large and still-growing community of integrators
and consultants focused on making a business of helping embedded
developers move their applications to Linux, for reasonable fees.

Conclusion

The goal of this article has been to give embedded developers some
insight into both the challenges they will face and benefits they will
realize from moving their entire software stack from a legacy RTOS to
Linux. The span of 2,800 words or so is too brief to delve into many of
the details of driver porting (driver APIs for bus interfaces, address
translation and so on), but the wealth of existing open-source GPL driver
code serves as both documentation and a template for your migration
efforts. The guidelines presented here should help your team
scope the effort involved in a port of RTOS to Linux and provide
heuristics for re-partitioning code for the best native fit to embedded
Linux.

As Director of Strategic Marketing and Technology Evangelist when he
wrote this article, Bill
focused his 17+ years of industry experience on advancing MontaVista
and embedded Linux in today's dynamic pervasive computing marketplace.
His background includes extensive embedded
and real-time experience with expertise in OS, tools, software licensing
and manufacturing.

Comment viewing options

As the author and a few commenters rightfully noted you can go the easy path by mapping all VxWorks tasks to Linux user mode processes/threads. The downside is that the performance hit can be huge (see above comment about mmap overhead).

Fortunately, it looks like now there is a solution - www.femtolinux.com allows to run user processes in kernel mode, removing the user/kernel barrier. FemtoLinux processes are pretty much identical to VxWorks tasks.

15 years as a VxWorks developer, now doing the linux side of the game. 99% of the time, the "real driver" approach is the preferred one - you get protection, etc. (I've ported almost all of my old VxWorks drivers to Linux that way) but there is the odd case - and I'm dealing with one now, where mmap() may buy you the realtime response you need - where even the interrupts are too slow.
(porting from linux to VxWorks is the easy direction - you're going from protected to unprotected,life is easy, aside from a few calls that aren't allowed.)
My catch at the moment though - on the architecture that I'm working with, is that the mmap call is expensive - more than you might think. Each access, by the time it has rolled up and unrolled the various page tables, is appearing to take 700ns - dropping memory bandwidth to less than 14MB/Sec. And that bytes. Pun intended.
Like everything, you've got to evaluate what you're doing, and why

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.