Re: Move RTAI modules to hal-linux?

Just FYI: the debian packages that John Morris made already install RTAI
modules in the kernel, and installing the modules is quite easy (you don't
need to know RTAI paths). I've also written up an init.d script to load and
unload RTAI modules by default:

https://github.com/ShabbyX/RTAI/blob/master/base/scripts/rtai-init

On RTAI installation (in the unofficial repo above), this init.d script is
also installed.

Note that in our repo, we also support multiple RTAI installations (where
the modules are not in the kernel naturally), so rtai-config-KERNEL scripts
are used instead of rtai-config. rtai-config instead detects
rtai-config-KERNEL scripts and passes the arguments along to the
appropriate one. For most cases, you would just add `-r` to select the
"running kernel". (I explained this because `-r` is used in the init.d
script I linked to above)

On Wed, Mar 30, 2016 at 3:47 PM, Alec Ari <[email protected]> wrote:

> Hello, is it just me or would it make more sense to have things like
> rtai_sched.ko be built by the kernel via Kconfig option in kernel source?
> I.e. /usr/src/linux - "press M to compile rtai_sched. The module will be
> called rtai_sched.ko"
>
> The reason I ask is because not all applications such as the RTAI
> testsuite load the modules when needed (this is why /proc/rtai is not a
> directory when running kern/display) and why would people be running a
> hal-linux kernel if they're not using RTAI? Xenomai is not 100% compatible
> with hal-linux (yes it's only a difference of about 10 lines compared to
> upstream IPIPE but that's besides the point) so Xenomaiers aren't going to
> be using hal-linux anyway (they have their own git tree as well for ipipe
> itself.) You might as well move all the kernel modules to the kernel and
> just have them loaded on init. Hal-Linux is already a separate project from
> IPIPE, why not go the whole nine yards?
>
>
> It'd save the trouble of needing to modprobe and unload before and after
> every instance. I must be missing something. RTDM is just set of driver
> code, couldn't this also be moved to kernel? With this, the kludgey RTAI
> design would be much easier to work on and trimmed down to LXRT, math and a
> few other things. RTAI is a very sensitive prone-to-break project and it's
> build system is flawed. Shahbaz and I have spent the last few years on and
> off cleaning up the tree and making it easier to work on, and I've pushed
> countless updates to the tree (just so Paolo can re-write them and slap his
> own name on my work) and I think (from experience of cleaning this project
> up as much as I have been) that moving obvious RTAI-dependant functions to
> hal-linux would ease this process dramatically. Simplifying and updating
> the build system, repairing the testsuite and overhauling how bits of the
> userspace are linked (especially LXRT) would also be a huge help for the
> developers. Because this project i
>  sn't an entry for IOCCC can we start some upstream mainline clean-up?
> Forking RTAI based off stable snapshots is not a good development plan (but
> will most likely always need to be the case at this rate.)
>
> Your feedback is greatly appreciated!
>
>
> Alec Ari
> _______________________________________________
> Rtai mailing list
> [email protected]
> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
>

_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai