Home header
Linux temps réel embarqué et outils de développements Technique





Study of the different possibilities to access the network from within RTLinux.
by Pierre Morel

Existing port and development

RTL-lwIP

  • a port of lwIP for rtlinux has been made by UPVLC
  • it uses Linux for PCI BUS interface
  • for now only two drivers, 3c905 and rtl8139
  • This project is close to the EtherbootD project and drivers from EtherbootD project are suuported by RTL-lwIP according to Sergio Perez, EtherbootD/RTL-lwIP developper.

rtsock

  • port from BSD (according to various mailing list)
  • uses Linux drivers
  • interface with Linux bottom half and Linux IP stack.

Possible port from RTAI

RTNET

  • port done for rtai
  • I do not know how good it may work
  • uses Linux for PCI BUS interface
  • 11 drivers issued from standard linux drivers

New port from existing TCP/IP stacks

I found 2 interressant projects for free TCP/IP stacks:

    lwIP (allready ported by UPV)
  • a port for drivers must be done
  • system integration: the difficulty seems to be medium, it needs an arch specific port, and uses threads, timers, semaphores
  • socket like API
    uip
  • a port for drivers must be done
  • system integration: easy event/callback
  • simple API

Ocera Network Daemon

Onetd uses the Linux TCP/IP stack indirectly from RTLinux through a communication system using SoftIRQ and a kernel thread daemon.

    Pro:
  • no port for driver has to be done
  • must run as good as the linux stack (it is the linux stack)
  • support for a all cards supported native by Linux
  • support for wireless, firewire
  • support for iptables filter, NAT and mangle tables.
  • support for bonding and vlan
  • can be used through VPN
    Contra:
  • needs to provide a socket API to RTLinux-GPL actual API is not POSIX at all.

My opinion

General:

The needs concerning RTLinux and SA-RTLinux are different.

for RTLinux with Linux

  • Complex network access may be done at Linux level.
  • a simple network interface may be propose to the RT level to facilitate network access developpment.
  • We can make usage of Linux drivers.

My candidate are rtsock and onetd.

The main difference between onetd and rtsocks is that rtsocks interface with linux bottom half and IP stack while onetd interfaces with linux kernel thread and TCP/IP stack.

RTSOCK

    Pro rtsock:
  • do not need Linux task to run, bh scheduling is enough
    Contra rtsock:
  • only part of UDP port, TCP is not ported (may be we do not need it)
  • need to be tested, I do not know all the implications of using directly the IP interface on ICMP and usage of the interface by other programs.
  • unclear License type

ONETD

    Pro onetd:
  • complete TCP and UDP implementation possible and quite easy
  • Feature rich through design
  • full compatible with Linux, Linux standard programms access the same interface
  • LGPL license (or other on need ... CECILL)
    Contra onet:
  • need to provide an easier, may be POSIX, API to RTLinux-GPL threads
  • actual implementation of the synchronization needs to be improved.

for SA-RTLinux

SA-RTLinux is not a priority for now,and I do not push the study very far but it seems to me that:

  • we need a complete new stack. rtnet,uip or lwIP
  • we need to developp drivers
  • My preference goes to uip as it is smaller and use event driven access. (this need a better study to see if it meets OCERA requirements)
  • lwIP provide more functionalities and is supported by an open group of developpers
  • a port of lwIP allready exists for RTLinux-GPL with Linux
  • EtherbootD drivers may be use in RTL-lwIP and are Linux independant.

Actual port of RTNet, cannot be use in SA-RTLinux as it uses Linux architecture. RTSocks and Onetd use Linux stack and cannot be used with SA-RTLinux.

Download onetd

The last development can be dowloaded from here: onetd-3.0d.tgz. or better, a debian package is available from here http://www.mnis.fr/fr/downloads/ and a complete Ocera Debian repository is available at: http://www.mnis.fr/ocera/ for woody and sarge (preffered).
This is a test release, with a BSD like API for UDP, most problems from the 2.2 release were fixed and the 3.0 release is stable.
Two demo programs are given for tests purpose and to be isued as skeleton for developments, a server (pong) a client (ping).
If you use Ocera-1.0, just do make, make install and modprobe onetd in the Ocera-3.0 directory. The load your application.
Things that need to be done:

  • more /procfs handling
  • more tests and ... bug fixes (certainly)
  • TCP connection handling

links


©M.N.I.S Society | Products | Services | Training | Support | Partners | News | Downloads ©M.N.I.S