Move RTAI modules to hal-linux?
Alec Ari <[email protected]>
| Newsgroups | gmane.linux.real-time.rtai |
|---|---|
| Message-ID | <[email protected]> |
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. Simplify ing 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