[En-Nut-Discussion] Porting Linux Apps to NutOS

[Ulrich Prinz]

Hi Bob,

On 05.11.2011 22:34, Bob Wirka wrote:
> Am I headed for disaster?
> 
> Using ethernut-4.8.9, Eclipse Helios, and the Codesourcery
> arm-none-eabi-xxx toolchain.
> 
Often used combination, looks fine to me.
> 
> We're porting a few applications from Linux to NutOS. All apps use
> networking (socket, bind, etc.). Trying to compile these projects
> using the headers from the compiler toolchain and ethernut is a
> nightmare. There is no socket support in the toolchain, and ethernut
> sockets don't fit the bill.

The idea was to provide a network stack for one of the smaller CPUs with
smallest possible overhead.
Later there where additional and more powerful CPUs added up to ARM9.
Even these CPU are already capable to run linux with good speed, the
basic idea of Nut/OS was kept and the CPUs where matched to NutOS not
backported from linux.

Nut/OS uses the posix threads interface but is internally handled to get
the most power out of very small chips. So there was no way of keeping
everything compatible to linux.
> 
> However, if you compile these applications as libraries (without any
> ethernut include paths) and specify the compiler toolchain include
> path first, followed last by a handy Linux include path, they will
> compile with only a little tweaking. Very clean.

That is right, as you can only use functions that your libc provides. As
you compile Nut/OS on the same compiler, Nut/OS will use the same libc.
So the two frontends match.
> 
> Now, when you link a library like this to a "core" program written
> for ethernut, you end up with a bunch of unresolved symbols;
> specifically the networking, threading, semaphore, and mutex
> functions. Then, if you write stub programs that transform those
> standard functions into Nut calls, you can get a good link. And,
> believe it or not, the programs run.

As long as you only call the functions that are provided by libc on both
sides, you will succeed. I do not see any reason why this should fail.
You already mentioned that size thing. You should check if the function
headers use architecture specific sizes in a matching way.

Ok, lets say you need _write( buf, file, sz, length);
_write is provided by libc as _write( void*, int, uint32_t, uint32_t)
But Nut/OS internally provides its own _write( void*, fp*, uint16_t, size_t)
Your application still thinks _write has the header of libc. No panic,
it was just an example.

> I'm thinking that since everyone agrees on the sizeof() things, this
> should work. Is there something lurking in all of this that will doom
> this approach?
> 
Not thought about that in detail ever before. But with some care taken
for the stubs, this should work.

Best regards
Ulrich