<div dir="ltr"><div class="gmail_extra">Dear Frank,<br><br></div><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The Etherlab developers are<br>
  obviously not interested in those changes, so I have to maintain<br>
  them myself.</blockquote><div><br></div><div>I'm not sure. They are rather in a continuous state of business, I would say.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- If I had known and considered all this back then, I might have<br>
  started with other code instead of Etherlab which is already<br>
  userspace based, but has different interfaces (and possibly<br>
  different bugs).</blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> But as things are now, since my code is tightly<br>
  bound to the Etherlab interface, and well tested with (the patched<br>
  version of) it, it seems easier to port this code to userspace<br>
  than change my application code.<br></blockquote><div><br></div><div>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.<br></div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Replace kernel infrastructure by corresponding userspace<br>
  functionality (e.g. kthread -> pthread, semaphore -><br>
  pthread_mutex, kmalloc -> malloc, kprintf -> fprintf); copy kernel<br>
  utilities that have no actual kernel dependencies (in particular<br>
  kernel lists).<br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Use the generic backend driver which also shouldn't require too<br>
  many changes since it already uses a raw ethernet socket which is<br>
  also available from userspace).<br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br><br><br></div><div>Jeroen.<br></div></div><br></div></div>