|
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
|