[etherlab-dev] Userspace fork of Etherlab

[Florian Pose]

Hallo Frank,

On Wed, Nov 26, 2014 at 06:31:18AM +0100, Frank Heckenbach wrote:
> this is to announce my plan to port the Etherlab code to userspace.
> I'll explain my reasons and roadmap below. If someone is interested
> in this or has some comments, please let me know. Otherwise, I
> expect to proceed on my own and publish the result on my web site
> when finished.

we discussed many of your arguments before, so let me comment on them
below.

> Reasons:
> 
> - I had to make a number of changes to the Etherlab code to fix some
>   bugs and make it useable to us. The Etherlab developers are
>   obviously not interested in those changes, so I have to maintain
>   them myself. As was discussed on this list some months ago,
>   keeping up with newer Etherlab versions would cost me additional
>   maintenance and testing effort (already now since my changes are
>   based on 1.5.0, whereas 1.5.2 has some conflicting changes), so
>   I'd use my own fork of 1.5.0 which is known to work for us rather
>   than 1.5.2 anyway.

I wrote, that I *am* willing to include your patches (I already prepared
the default branch to include them), but due to my running projects I am
a little later than expected, but I'm sure I will manage it this year.
So please be unpatient, this is an open-source project.

> - Keeping up with new kernel versions is also not always easy
>   (especially for the drivers which are patched files from the
>   standard kernel, but also other kernel interfaces are known to
>   change often), whereas userspace code is much easier to maintain
>   (incompatible library changes are quite rare).

The problem is, that using a socket (generic driver) is not always
sufficient. My first goal is to keep stable interfaces for RTAI, Xenomai
(Kernel) and lxrt, posix (Userspace). Using a socket automatically uses
the lower network stack layers and is *not* realtime-capable up to now
(even with an RT-preempt-patched kernel). So the generic driver is one
option. It may work, but there are setups where it definitely does not.
That's why we keep the native drivers and have to stay in kernel (at
least with the driver layer).

> - So far we've been using RTAI for our realtime code. But that's
>   also always been a bit troublesome (kernel version dependencies,
>   high crash potential in case of problems, additional code with its
>   own set of bugs, etc.), so we'd rather try to get rid of it
>   anyway. Meanwhile the RT capabilities of the standard kernel have
>   improved in recent years, and due to the wide availability of SMP,
>   we can, if necessary, increase RT-ability by using CPU affinity
>   (reserve one CPU for RT code, leave the other CPUs for the rest --
>   of course, kernel code, esp. network drivers might need special
>   consideration here).

We also dropped RTAI a long time ago for our projects, but you have to
always be grateful in what you support, because there are many users
that still require RTAI, lxrt, etc.

> - Our application code uses a lot of floating point which is
>   supported in RTAI (though with some quirks), not in non-RTAI
>   kernel mode, but of course easily in userspace.

Noone forces you to have your application in kernel space. The
userspace-library offers the same API in userspace.

> - Userspace code is generally much easier to debug.
> 
> - If I had known and considered all this back then, I might have
>   started with other code instead of Etherlab which is already
>   userspace based, but has different interfaces (and possibly
>   different bugs). But as things are now, since my code is tightly
>   bound to the Etherlab interface, and well tested with (the patched
>   version of) it, it seems easier to port this code to userspace
>   than change my application code.

Your argumentation sounds a little bit like you don't know of the
userspace library at all. Please take a look in the documentation and
the lib/ subdirectory of the stable-1.5 branch. Our realtime
applications of the last years are alltogether in userspace.


I had the idea to pull the master statemachine out of kernel-space but I
dropped it because of the additional interface complexity coming with
it.

As long as the generic driver is not completely realtime capable and the
kernel interfaces shall be maintained, there are strong arguments to
keep a significant part of the master code in kernel-space.

-- 
Best regards,
Florian Pose

http://etherlab.org