Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Norbert Lange <nolange79@gmail.com>]

Hi,

not really happy to hear that, but this was already my impression.
There is alot of knowledge of kernel, hardware and bootloader
knowledge necessary to be able to maintain the ipipe patch, as
newcomer to most of these I am just helpless. Unless someone is
dedicated to that,
there is not chance to keep up.

What you could do is to automate as much as possible, saving some of
the regular grinding work.
The way realtime is used with minimal configurations, FTB errors will
show up late,
and changes in kernel APIs are only carried over in actively used drivers.

ie.
-   automated builds with several kernel configs
-   potential some tests under qemu with the above.

Buildroot does something similar, and this is very low maintenance
cost once its setup,
could automatically report issues or non-working config-switches.
Nowadays you can let providers like Gitlab take care of keeping the
servers running,
as I understand it you have no limits to build-time unless the project
is private.
You get some good issue tracking on top of it, patches can be
automatically checked in form of merge-requests.
(In the unlikely case they go bust or get unfriendly, you can still
tun an older Gitlab version on your own server)


I really don`t see the advantage in separating the subprojects,
its already complicated enough to piece everything together,
and with automated builds you could atleast catch build-errors or fails-to-boot.
I take unmaintained, but buildable code in-tree over unmaintained code
in a separate project everyday.

Publicity

Dont know how to takle this, but its very easy to get a full IDE and
start programming some embedded CPUs.
Commercial OSes have a huge advantage there, cause it doesnt take much
to get example code running (youre only going to hit walls as your
problems get bigger than their ecosystem). First impressions count,
and being able to debug through code gets you firsthand knowledge
faster than any other approach.

In that respect some known-to-work hardware with known-to-work
dual-kernel with a pre-setup dev environment would go a long way to
ease the first steps and might gather some new interested users.
Some cheap, high-volume, jtag-debugable SBC would do.

Otherwise theres some architecture-, bios- and ever changing
kernel-magic involved just to get a plain system running.