[etherlab-dev] Userspace fork of Etherlab

[Jeroen Van den Keybus]

Dear Frank,


The Etherlab developers are
>   obviously not interested in those changes, so I have to maintain
>   them myself.


I'm not sure. They are rather in a continuous state of business, I would
say.

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


It is often instructive to review why you made the initial choice. You
could be forgetting important positive arguments. For me, that would
include the fact that Etherlab is a clean, well-structured project which
has a sizeable user group.


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

If it get it correctly, you consider porting your code that is running in
kernel space to user space. I would say that, depending on your platform,
that conversion is a no-brainer and Etherlab has little to do with that.

- Replace kernel infrastructure by corresponding userspace
>   functionality (e.g. kthread -> pthread, semaphore ->
>   pthread_mutex, kmalloc -> malloc, kprintf -> fprintf); copy kernel
>   utilities that have no actual kernel dependencies (in particular
>   kernel lists).
>

Have you considered using Xenomai ? It has a POSIX skin and, since version
3, you should be able to run under RT-Preempt as well as the native I-pipe
using the same code. It is a very high quality project that is well
maintained.

I do not know what your application is and how time-critical it is, but you
will occasionally have to deal with increased latencies and I fear that
dealing with these occurrences may cost you much more in terms of
catch-coding than selecting a real-time environment in the first place.


> - Use the generic backend driver which also shouldn't require too
>   many changes since it already uses a raw ethernet socket which is
>   also available from userspace).
>

The raw ethernet socket has limited zero-copy capability and not every
driver is optimized for it. It's great (and designed) for capturing massive
amounts of traffic (mostly Wireshark), but low latency was never the
objective. Be warned.

I'm trying to convince you to reconsider your choice to fork, because I
think that the choice may not be based on the correct arguments, but also
because Etherlab would benefit from as large a user base as it can get. In
a sense, it is already a niche project as it is.


Jeroen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20141126/22c42a85/attachment.html>