1
votes

I'm working on a project aimed to control a bipad robot supposed to play soccer game. All programs are written in plain C++ linked against various shared libraries (for example OpenCV, Servo-motor controllers, etc.)

The system is performance critical and should be 95% hard real-time, so the Xenomai patch has been applied to kernel. Unfortunately benchmarks on thread-switch latency, shows the system does not satisfy hard real-time needs in all situations. Duo to this work. we can improve performance by porting all stuff into kernel space.

I never developed kernel modules... Just read some documentations. Seems to be different with regular user-space programs. Even build system is different.

My question: Is this possible to turn a regular user-space application written entirely in C++, widely using shared libraries, and POSIX threads into a kernel module?

If the answer is no, I'm gonna re-compile all libraries statically and use C instead... That will be harmful and time consuming process.

1
I don't think it is easy to turn a user-space application into a kernel module if even possible. Usually it is not just a matter of using C and recompilation. The libraries (not to mention libc itself) make things even more complex. Perhaps it could be easier to move only the most performance-critical parts of the application to a separate kernel module, most likely written from scratch, and make the application use that module. It could take some time though. May be the experts out there have better ideas on what to do here.Eugene

1 Answers

3
votes

First, if you want hard real-time, you should use a hard real-time system, not Linux. Linux can do some real-time, but does not infer hard guarantees on deadlines.

But to answer your question, no, it is not possible to turn a C++ application into a kernel module because the kernel lacks the C++ runtime that would make it possible. In kernel space you cannot even use libc, let alone libstdc++.

Recompiling all your libraries statically would not be any better. First this means you would ultimately have to port libc to kernel space, which is not doable (as libc invokes the kernel itself through system calls). Also you typically want to keep the amount of code that goes into the kernel (and takes down the whole system with it whenever it fails) as small as possible.

If sounds more like your application needs to be redesigned in order to limit thread latency (either by using a lighter threading library, or by reducing the number of thread switches). Anyway if you use threads in the kernel, you will still have latency - and the only gain you might have would be the absence of system calls.

So my guess is that you need to think about design rather than moving stuff into the kernel.