Patches to RTAI

[ShabbyX]

Hi John,

I'm planning on applying your patches here to the RTAI tree, and I would appreciate if you let me know which ones are necessary (perhaps some are just for the debian packaging?), and if the patch is non-trivial, what does it do.

By the way, could it be this line in autogen.sh generates the files you added in https://github.com/zultron/RTAI/commit/c18582723066006c225d4926fa234cd5ce7f4e12, and that's why we hadn't had need for them?

[zultron]

Hi Shabby, I'll address the patches one by one:

fix-autotools-files.patch

This is from the upstream Debian maintainer. I don't understand some of it, like why he both includes new copies of config.sub and config.guess and updates the existing copies of those already in the source. Changing $(prefix)/include to @includedir@ is a good change, but I don't understand why the changes to base/scripts/rtai-config.in.

fix-headers.patch
fix-include-comedilib-h.patch

More patches from the upstream maintainer that I wouldn't understand without doing some homework. Maybe consult with the original author, Roland Stigge?

re-add-autoconf-files.patch

This addresses ShabbyX/RTAI issue 15, and your last question above. The reason you hadn't needed these files before is they are included in the distro. It might be ok not to include this patch, but then they should be properly detected with meaningful error messages when they're missing, and there could be distros that don't ship them or don't ship appropriate versions, although Debian and Red Hat look fine.

rtai-config-multi-kernel.patch

This patch addresses ShabbyX/RTAI issue 16.

rtai-preferred-stack-boundary.patch

This addresses a problem using FP code in newer kernels with newer GCCs.

set-default-rtai_cpus.patch

This patch simply bumps up RTAI_CPUS to 8; RTAI breaks when running on systems with more CPUs than configured here.

Thanks for looking at this!

[ShabbyX]

Thanks for the explanations! I'll ask Roland about the first three patches. I'll immediately apply patch 4, 6 and 7.

About patch 5 (multi-kernel), I wanted to talk to you about a minor issue (which I'll write in ShabbyX/RTAI#16)

[ShabbyX]

Done with patches 4, 6 and 7. For future, please consider git format-patch instead of git show! :) git am doesn't accept the output of git show, so there is some manual work involved

[zultron]

@ShabbyX, I realized that a couple of the upstream patches in the package aren't applied, even though they're still in the patches directory:

fix-autotools-files.patch
fix-headers.patch

This is the only upstream patch still carried in the package:

fix-include-comedilib-h.patch

Just FYI.

[ShabbyX]

Yeah I know. If you recall from zultron/rtai-deb#1, those were the patches whose intentions were a bit fuzzy. I emailed Roland Stigge for clarification before applying them, especially fix-headers.patch which touches some arch/asm-*/ files that seem to be working fine without the patch.

I didn't get a reply, so I'm still not sure to what degree it's important to have them. I'll try to research them in the weekend though, perhaps I would be able to understand something!

[zultron]

The last patch still carried in the package, fix-include-comedilib-h.patch, does exactly what it appears: the Debian and Ubuntu libcomedi-dev package puts headers directly in /usr/include, not in any directory path ending with linux:

$ find /usr/include -name comedilib.h
/usr/include/comedilib.h
$ dpkg-query -S /usr/include/comedilib.h
libcomedi-dev: /usr/include/comedilib.h
$ dpkg-query -L libcomedi-dev | grep linux/
$ 

I'm trying to figure out in what case the header's location might be in /usr/include/linux/comedilib.h. Debian, Ubuntu and Fedora all install into /usr/include/comedilib.h, and building comedilib from source apparently does, too. It's starting to look like /usr/include/linux/comedilib.h is an outdated location, or maybe completely bogus: this problem has been reported since at least 2004, and hacking around the problem with a symlink is part of at least one RTAI tutorial!