Re: [Emc-developers] RTAI broken again with LinuxCNC
Whelp, pull request submitted. Just be sure to test the math! https://github.com/LinuxCNC/linuxcnc/pull/2685 The 2.9 branch will be broken with newer RTAI without this, so if it works in master I'd cherry-pick it. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Sat, 7 Oct 2023 at 00:00, Alec Ari via Emc-developers wrote: > > I don't exactly know why switching to GNU11 causes this issue, maybe the > GNU11 standard already defines these, but I removed LinuxCNC's definitions of > the following functions: > > atan > asin > acos > fmax > fmin That looks like it shouldn't break usapce, as is wrapped in #ifdef _KERNEL_ The odd thing is that there are clearly duplicate definitions in there, in that single file. Perhaps the difference is that gnu11 flags bring in a different set of error checks? For example I have noticed that the RTAI build gets mildly upset about switch statements which fall-through. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
I can't tell because my C skills are pretty bad but looking at fmax and fmin,
I'm worried that the X and Y axis might be flipped for example:
LinuxCNC from rtapi_math.h:
extern __inline double fmax(double __y, double __x) {
return __y > __x || __builtin_isnan(__x) ? __y : __x;
}
extern __inline double fmin(double __y, double __x) {
return __y < __x || __builtin_isnan(__x) ? __y : __x;
}
RTAI from musl/libm/f{max,min}.c:
double fmax(double x, double y)
{
if (isnan(x))
return y;
if (isnan(y))
return x;
/* handle signed zeros, see C99 Annex F.9.9.2 */
if (signbit(x) != signbit(y))
return signbit(x) ? y : x;
return x < y ? y : x;
}
double fmin(double x, double y)
{
if (isnan(x))
return y;
if (isnan(y))
return x;
/* handle signed zeros, see C99 Annex F.9.9.2 */
if (signbit(x) != signbit(y))
return signbit(x) ? x : y;
return x < y ? x : y;
}
Or maybe everything will just work perfectly fine! :-)
Alec
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
I can make a pull request, I'm pretty sure the appropriate fix is indeed the correct fix. I think it'd be important to test the implementations of atan, asin, acos, fmax and fmin to make sure all is well. LinuxCNC will report errors if any of the math is wrong, yes? Say for example the accuracy of atan is off by a few decimal points, how will the user know if there's a problem? I'm fairly certain this will be a non-issue but I just want to make sure switching from GNU89 to GNU11 doesn't come with any regressions. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
I don't exactly know why switching to GNU11 causes this issue, maybe the GNU11 standard already defines these, but I removed LinuxCNC's definitions of the following functions: atan asin acos fmax fmin from rtapi_math.h and had to remove -Werror=frame-larger-than=2560 from LinuxCNC's Makefile and everything seems to be working now. commit: https://github.com/NTULINUX/linuxcnc-rtai-gnu11/commit/f436cfbc1514f9b52f29486648c1fca8ffcc7d5f Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Mon, 2 Oct 2023 at 00:14, Alec Ari via Emc-developers wrote: > > Oh crap, I'm seeing these too. This might be because of the gnu11 changes but > I'll have to look into this more. Yes, trig errors everywhere. I am only seeing them so far in hostmot2. Might be worth commenting out hostmot2 in the makefile to see if it really is that, ot just that that is first. (Hostmot2 has a large number of sub-files, and they all seem to raise the problem) -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
Oh crap, I'm seeing these too. This might be because of the gnu11 changes but I'll have to look into this more. Yes, trig errors everywhere. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Sun, 1 Oct 2023 at 21:25, andy pugh wrote: > I suspect that this is because you worked musl into rtail_math.ko? > Though there may be lots of other explanations. It looks like we have always loaded rtai_math.ko. So I don't actually know where to look now. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Sat, 30 Sept 2023 at 23:27, Alec Ari via Emc-developers wrote: > > Not a problem, I will build RTAI 5.4.256 kernel packages and rtai-modules > with the `gnu11` branch. Just be sure to revert the gnu89 commit for > limit_axis when testing the debs. I'm not sure when I'll exactly get around > to this but I got it. I built the kernel and the RTAI modules. After a bit of trouble with raster.comp and hal_speaker I now find an interesting issue compiling hostmot2, duplicate definitions of all the trig functions. If I delete the include for rtapi_math.h then I get a bit further, until encoder.c fails trying to use "fabs". I suspect that this is because you worked musl into rtail_math.ko? Though there may be lots of other explanations. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Sat, 30 Sept 2023 at 23:45, andy pugh wrote: > Don't bother with the kernel, I have that done already. If you have them, then carry on. But I think I am nearly there, other than RTAI just installing in /usr/realtime (with no kernel suffix) But, it's time to stop for the day. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Sat, 30 Sept 2023 at 23:27, Alec Ari via Emc-developers wrote: > > Not a problem, I will build RTAI 5.4.256 kernel packages and rtai-modules > with the `gnu11` branch. Just be sure to revert the gnu89 commit for > limit_axis when testing the debs. I'm not sure when I'll exactly get around > to this but I got it. Don't bother with the kernel, I have that done already. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
Not a problem, I will build RTAI 5.4.256 kernel packages and rtai-modules with the `gnu11` branch. Just be sure to revert the gnu89 commit for limit_axis when testing the debs. I'm not sure when I'll exactly get around to this but I got it. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Sat, 30 Sept 2023 at 22:40, Alec Ari via Emc-developers wrote: > Then skip to line 92, Creating RTAI Debian packages > > That's a really odd problem that I've never before. I was able to build RTAI > kernel and module packages on Debian 12, forget my exact release. > > If it fails again, I'll host the deb packages on my Github. Following those > instructions though you should have no problems. I think, for the moment, it would help if you had an RTAI deb package that I could try. I probably need to start from scratch and that will take several hours. Currently attempting to build a .deb package fails like this: andypugh@rm-one:~/RTAI$ dpkg-buildpackage -uc -us dpkg-buildpackage: info: source package rtai dpkg-buildpackage: info: source version 5.3.3-linuxcnc-delta dpkg-buildpackage: info: source distribution bullseye dpkg-buildpackage: info: source changed by Alec Ari dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build . fakeroot debian/rules clean dh_testdir rm -f build-stamp debian/rtai-modules-5.4.256.files dh_clean dh_clean: warning: Compatibility levels before 10 are deprecated (level 9 in use) dpkg-source -b . dpkg-source: info: using source format '1.0' dpkg-source: warning: native package version may not have a revision dpkg-source: warning: source directory 'RTAI' is not - 'rtai-5.3.3-linuxcnc' dpkg-source: info: building rtai in rtai_5.3.3-linuxcnc-delta.tar.gz dpkg-source: info: building rtai in rtai_5.3.3-linuxcnc-delta.dsc debian/rules build dh_testdir # Build RTAI ./autogen.sh --enable-cpus=8 --with-linux-dir=/usr/src/linux-headers-5.4.256-rtai-amd64 /usr/src/linux-headers-5.4.256-rtai-amd64_5.4.256-rtai-amd64-1_amd64.deb --prefix=/usr/realtime-5.4.256-rtai-amd64 --libdir=/usr/lib --includedir=/usr/include/rtai --host=x86_64-linux-gnu autoreconf: export WARNINGS= autoreconf: Entering directory '.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I m4 autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy autoreconf: configure.ac: not using Intltool autoreconf: configure.ac: not using Gtkdoc autoreconf: running: aclocal -I m4 autoreconf: running: /usr/bin/autoconf autoreconf: running: /usr/bin/autoheader autoreconf: running: automake --add-missing --copy --no-force autoreconf: Leaving directory '.' configure: WARNING: you should use --build, --host, --target configure: WARNING: invalid host type: /usr/src/linux-headers-5.4.256-rtai-amd64_5.4.256-rtai-amd64-1_amd64.deb checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for x86_64-linux-gnu-strip... x86_64-linux-gnu-strip checking for a race-free mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking build system type... Invalid configuration `/usr/src/linux-headers-5.4.256-rtai-amd64_5.4.256-rtai-amd64-1_amd64.deb': machine `/usr/src/linux-headers-5.4.256-rtai-amd64_5.4.256-rtai-amd64' not recognized configure: error: /bin/bash ./scripts/autoconf/config.sub /usr/src/linux-headers-5.4.256-rtai-amd64_5.4.256-rtai-amd64-1_amd64.deb failed Error running configure. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
I would do a `make mrproper` and follow these steps for the kernel build: https://github.com/NTULINUX/RTAI/blob/gnu11/README.INSTALL Then skip to line 92, Creating RTAI Debian packages That's a really odd problem that I've never before. I was able to build RTAI kernel and module packages on Debian 12, forget my exact release. If it fails again, I'll host the deb packages on my Github. Following those instructions though you should have no problems. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Sat, 30 Sept 2023 at 13:17, andy pugh wrote: > FATAL: parse error in symbol dump file Probably due to skipping the "make modules" stage of the kernel build, as I went straight to the deb build. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Thu, 28 Sept 2023 at 03:28, Alec Ari via Emc-developers wrote: > > Yes, use the gnu11 branch in my RTAI tree and pick either 4.19.294 or or > 5.4.256 I have switched to Debian 12 and kernel 5.4.256-rtai I am having trouble compiling RTAI: Making all in src make[2]: Entering directory '/home/andypugh/RTAI/src' Making all in sched make[3]: Entering directory '/home/andypugh/RTAI/src/sched' CC calibrate-calibrate.o CCLD calibrate CC [M] /home/andypugh/RTAI/src/sched/rtai_hal.o Building modules, stage 2. MODPOST 1 modules FATAL: parse error in symbol dump file make[5]: *** [scripts/Makefile.modpost:93: __modpost] Error 1 make[4]: *** [Makefile:1667: modules] Error 2 make[3]: *** [GNUmakefile:703: rtai_hal.ko] Error 2 make[3]: Leaving directory '/home/andypugh/RTAI/src/sched' make[2]: *** [GNUmakefile:374: all-recursive] Error 1 make[2]: Leaving directory '/home/andypugh/RTAI/src' make[1]: *** [GNUmakefile:438: all-recursive] Error 1 make[1]: Leaving directory '/home/andypugh/RTAI' make: *** [GNUmakefile:370: all] Error 2 "parse error in symbol dump file" isn't a lot to go on. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
Yes, use the gnu11 branch in my RTAI tree and pick either 4.19.294 or or 5.4.256 As an additional layer of testing, revert the C89 commit in LinuxCNC to make sure GNU11 `for` loops actually work as intended: https://github.com/LinuxCNC/linuxcnc/commit/3d926d87f14ada9dea313c2989ee8f24f0e54e0c If there is a way to test limit_axis.ko please do so. If all is well, I'll merge everything together into the RTAI `master` branch. Thanks Andy! It's always fun squashing bugs with you. Alec On Thursday, September 28, 2023 at 12:46:23 AM UTC, andy pugh wrote: Do I need to re-build RTAI? My current git pull is master from https://github.com/NTULINUX/RTAI.git -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Thu, 28 Sept 2023 at 00:41, Alec Ari via Emc-developers wrote: > Would anyone be able to test LinuxCNC against the changes I'll be making to > RTAI? I can only test the sims, I don't have any actual CNC hardware > available. I can. Do I need to re-build RTAI? My current git pull is master from https://github.com/NTULINUX/RTAI.git -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
Hi all, Rene said I should switch RTAI to GNU11: https://github.com/LinuxCNC/linuxcnc/commit/3d926d87f14ada9dea313c2989ee8f24f0e54e0c#commitcomment-128557906 I suppose the above commit could be reverted. Would anyone be able to test LinuxCNC against the changes I'll be making to RTAI? I can only test the sims, I don't have any actual CNC hardware available. I can make deb packages for the kernel, headers and rtai-modules but LinuxCNC still doesn't support building RTAI deb packages so it will need to be run-in-place. Kernels will be 4.19.294 and 5.4.256 genserkins still doesn't build though due to stack frame size being too large, the value from 2560 needs to be larger (-Werror=frame-larger-than=2560) That value comes from LinuxCNC/src/Makefile in EXTRA_CFLAGS: https://github.com/LinuxCNC/linuxcnc/blob/master/src/Makefile#L891 Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
Moving forward, I can merge that C11 patch into RTAI so we don't have to worry about C89/gnu89 anymore and you can just code how you please :-) I haven't noticed any regressions with the little testing I did but there could be something down road. I guess it depends on how often/how much C11 code is expected to be written in LinuxCNC. I don't know but I'm fine making that change. Hey Andy, just want to say it's always fun working with you on these things. Have you been able to build genserkins just fine btw against RTAI? Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Wed, 20 Sept 2023 at 23:27, Alec Ari via Emc-developers wrote: > > I don't know if this code is right, I just copied and pasted the 32 versions > and made 64 versions where required. I have been struggling with raster.comp, or more specifically with its test. I think I need to reboot into a preempt-rt kernel to see if it works there. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
I don't know if this code is right, I just copied and pasted the 32 versions and made 64 versions where required. https://github.com/LinuxCNC/linuxcnc/pull/2650 Undefined symbols are gone, please review before merging! Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Wed, 20 Sept 2023 at 18:17, Alec Ari via Emc-developers wrote: > > Since the fix is as simple as moving an, "i" around, I say we just do that. > Problem solved. And done, on 2.9. Merged into a local branch of master to be pushed after > If there is no way to have raster.comp not depend on userspace headers, it > should simply be excluded in the RTAI build. It includes stdlib.h to get strtol(), strtod() and strtoul(), These are available in kernel space as kstrtol() and friends, or the old and deprecated simple_strtol, I have chosen to use the latter to modify raster.comp and that avoids the problem, though I am not sure that simple_strtol is a 100% suitable substitute for strtod() and strtoul(). I chose it because our rtapi defines simpl_strtol() as stldib/strtol in user space, so it saves trouble. With these changes the RTAI build then works, but starting a halrun session gives: https://github.com/LinuxCNC/linuxcnc/commit/7a4c0908567e27f034c7cb2fe2f6c5b1341c933c#commitcomment-127914249 I think this is probably a general issue, but only gets spotted at load-time with kernel modules -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
So, there are two ways of building kernel modules with GNU11 instead of gnu89 or C99. 1.) Do it in RTAI: https://github.com/NTULINUX/RTAI/commit/a649bbb40fad9299ba31285276d9204df2f222d9 2.) Do it in LinuxCNC: https://github.com/NTULINUX/linuxcnc/commit/a76b69f7e66f7a3831be655ea3dde4590502a175 The first commit builds both the RTAI math module (rtai_math.ko) and musl with GNU11 (thorough explanation in git message.) The second is more conservative; building only the LinuxCNC modules with GNU11. I think it makes more sense doing this in RTAI so everything just matches. I hacked away at the LinuxCNC sources to try and get a successful build going but now I'm getting this: Reading 205/205 dependency files Done reading dependencies MAKEFLAGS="" \ /usr/bin/python3.11 modsilent.py make KBUILD_EXTRA_SYMBOLS=/usr/realtime/modules/Module.symvers -C /lib/modules/4.19.294-rtai-amd64/build M=/home/ntu/linuxcnc/src CC=gcc V=0 modules make[1]: Entering directory '/usr/src/linux-headers-4.19.294-rtai-amd64' Building modules, stage 2. MODPOST 213 modules WARNING: "hal_param_u64_new" [/home/ntu/linuxcnc/src/hal_lib.ko] undefined! WARNING: "hal_param_s64_newf" [/home/ntu/linuxcnc/src/hal_lib.ko] undefined! WARNING: "hal_param_u64_newf" [/home/ntu/linuxcnc/src/hal_lib.ko] undefined! WARNING: "hal_param_s64_new" [/home/ntu/linuxcnc/src/hal_lib.ko] undefined! make[1]: Leaving directory '/usr/src/linux-headers-4.19.294-rtai-amd64' dmesg when trying to start latency-test: [ 6404.916638] hal_lib: Unknown symbol hal_param_s64_new (err -2) [ 6404.916646] hal_lib: Unknown symbol hal_param_u64_newf (err -2) [ 6404.916660] hal_lib: Unknown symbol hal_param_s64_newf (err -2) [ 6404.91] hal_lib: Unknown symbol hal_param_u64_new (err -2) Any help is greatly appreciated. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Wed, 20 Sept 2023 at 18:05, Chad Woitas via Emc-developers wrote: > For what its worth, I’ve actually stopped running linuxcnc on a realtime > kernel since 5.14 for most of my development machines, and they’re running > better than expected with sub 1ms cycle times on an i5-6600. Not realtime at all, or are you running preempt-rt? There are several options: Linuxcnc-uspace on a standard kernel - OK for sim, not for motion control Linuxcnc-uspace on the preempt-rt kernel - Good enough for most purposes. Especially with FPGA cards, and the only option for Ethernet Mesa cards. Linuxcnc-RT on the RTAI kernel - Gives the best latency, generally. But that isn't always needed. Linuxcnc-uspace on the RTAI kernel - needs the linuxcnc-uspace-rtai deb installed, works pretty well running RTAI with LXRT - May work with ethernet mese Linuxcnc-uspace on the Xenomai kernel - needs linuxcnc-uspace-xenomai to run with LXRT - I have not tested this To install the preempt-rt kernel there is no need to compile anything. Just sudo apt-get install linux-image-rt-amd64 and then reboot. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
Since the fix is as simple as moving an, "i" around, I say we just do that. Problem solved. Even with a Xenomai 4/Dovetail/EVL port, you can't mix C library userspace headers with kernel space. The musl C library port I did with RTAI's current infrastructure is special because without it, you can't do floating-point in kernel space. It is a practice that should by all means be avoided. If there is no way to have raster.comp not depend on userspace headers, it should simply be excluded in the RTAI build. I'm using 2.9 and master. Note that without RTAI, you will not see the problem. Andy, you hit the nail on the head: >I think that the problem is that folk writing HAL components for >LinuxCNC don't realise that they are writing "Kernel sources for >kernel 4.19" and if they compile, build and test on uspace they won't >see any problems. They are indeed writing kernel modules. :-) Alec On Wednesday, September 20, 2023 at 09:47:14 AM UTC, Rod Webster wrote: I don't see why limit_axis.comp can't be revised to declare the int i; at the top of the procedure which I was taught was best practice anyway. That would solve the C11/C89 issue. raster.comp needs stdlib.h for some of the conversion functions. It also should include string.h for strchr() so it's still a bit sloppy. Surely your compiler library includes could be modified or set in the ENV to include these. What version of linuxcnc are you using? I could not see the size error in genserfuncs.c in master branch. We really should not be taking responsibility for the RTAI kernel compatibility. That has to be their problem, not ours. The Linux Kernel 6.5 has been released so that seems to be 11 versions ahead of the last RTAI compatible kernel. When do we accept that RTAI is really yesterday's technology? Where is the port to Xenomai 4? Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Wed, 20 Sept 2023 at 18:27, andy pugh wrote: > On Wed, 20 Sept 2023 at 01:17, Alec Ari wrote: > > > Seriously though, the proper way to fix this is to not use c11/gnu11 > with 4.19 or 5.4 kernel sources. > > I think that the problem is that folk writing HAL components for > LinuxCNC don't realise that they are writing "Kernel sources for > kernel 4.19" and if they compile, build and test on uspace they won't > see any problems. > > Is there any fundamental reason that _our_ kernel modules can't be > compiled with gnu11 ? > > > -- > atp > "A motorcycle is a bicycle with a pandemonium attachment and is > designed for the especial use of mechanical geniuses, daredevils and > lunatics." > — George Fitch, Atlanta Constitution Newspaper, 1912 > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
Interesting, I was taught this increases the risk of duplicate variable use:
IE:
void some_fcn(){
int i=0;
for(i=50; ihttp://www.rmd-engineering.com/> | Saskatoon Machine Works
Ltd.<http://www.smw.sk.ca/> | Scientific Instrumentation
Ltd.<http://www.sil.sk.ca/>
The information contained in this message is confidential or protected by law.
If you are not the intended recipient, please contact the sender and delete
this message.
Any unauthorized copying of this message or unauthorized distribution of the
information contained herein is prohibited.
From: Rod Webster<mailto:r...@vehiclemods.net.au>
Sent: September 20, 2023 3:48 AM
To: EMC developers<mailto:emc-developers@lists.sourceforge.net>
Subject: Re: [Emc-developers] RTAI broken again with LinuxCNC
I don't see why limit_axis.comp can't be revised to declare the int i; at
the top of the procedure which I was taught was best practice anyway. That
would solve the C11/C89 issue.
raster.comp needs stdlib.h for some of the conversion functions. It also
should include string.h for strchr() so it's still a bit sloppy. Surely
your compiler library includes could be modified or set in the ENV to
include these.
What version of linuxcnc are you using? I could not see the size error in
genserfuncs.c in master branch.
We really should not be taking responsibility for the RTAI kernel
compatibility. That has to be their problem, not ours. The Linux Kernel
6.5 has been released so that seems to be 11 versions ahead of the last
RTAI compatible kernel. When do we accept that RTAI is really yesterday's
technology? Where is the port to Xenomai 4?
Rod Webster
*1300 896 832*
+61 435 765 611
Vehicle Modifications Network
www.vehiclemods.net.au<http://www.vehiclemods.net.au>
On Wed, 20 Sept 2023 at 18:27, andy pugh wrote:
> On Wed, 20 Sept 2023 at 01:17, Alec Ari wrote:
>
> > Seriously though, the proper way to fix this is to not use c11/gnu11
> with 4.19 or 5.4 kernel sources.
>
> I think that the problem is that folk writing HAL components for
> LinuxCNC don't realise that they are writing "Kernel sources for
> kernel 4.19" and if they compile, build and test on uspace they won't
> see any problems.
>
> Is there any fundamental reason that _our_ kernel modules can't be
> compiled with gnu11 ?
>
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
I don't see why limit_axis.comp can't be revised to declare the int i; at the top of the procedure which I was taught was best practice anyway. That would solve the C11/C89 issue. raster.comp needs stdlib.h for some of the conversion functions. It also should include string.h for strchr() so it's still a bit sloppy. Surely your compiler library includes could be modified or set in the ENV to include these. What version of linuxcnc are you using? I could not see the size error in genserfuncs.c in master branch. We really should not be taking responsibility for the RTAI kernel compatibility. That has to be their problem, not ours. The Linux Kernel 6.5 has been released so that seems to be 11 versions ahead of the last RTAI compatible kernel. When do we accept that RTAI is really yesterday's technology? Where is the port to Xenomai 4? Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Wed, 20 Sept 2023 at 18:27, andy pugh wrote: > On Wed, 20 Sept 2023 at 01:17, Alec Ari wrote: > > > Seriously though, the proper way to fix this is to not use c11/gnu11 > with 4.19 or 5.4 kernel sources. > > I think that the problem is that folk writing HAL components for > LinuxCNC don't realise that they are writing "Kernel sources for > kernel 4.19" and if they compile, build and test on uspace they won't > see any problems. > > Is there any fundamental reason that _our_ kernel modules can't be > compiled with gnu11 ? > > > -- > atp > "A motorcycle is a bicycle with a pandemonium attachment and is > designed for the especial use of mechanical geniuses, daredevils and > lunatics." > — George Fitch, Atlanta Constitution Newspaper, 1912 > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Wed, 20 Sept 2023 at 01:17, Alec Ari wrote: > Seriously though, the proper way to fix this is to not use c11/gnu11 with > 4.19 or 5.4 kernel sources. I think that the problem is that folk writing HAL components for LinuxCNC don't realise that they are writing "Kernel sources for kernel 4.19" and if they compile, build and test on uspace they won't see any problems. Is there any fundamental reason that _our_ kernel modules can't be compiled with gnu11 ? -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
See the links I posted, they link to the lines in the kernel Makefile, that's where the gnu89 is coming from. Seriously though, the proper way to fix this is to not use c11/gnu11 with 4.19 or 5.4 kernel sources. It probably won't even work and shouldn't be tried. 4.19 and 5.4 use gnu89. https://stackoverflow.com/questions/29338206/error-for-loop-initial-declarations-are-only-allowed-in-c99-mode Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Tue, 19 Sept 2023 at 23:12, Alec Ari via Emc-developers wrote: > LinuxCNC may set -std=gnu11 however that covers userspace only (i.e. > PREEMPT_RT builds.) > > All kernel modules are still gnu89. Do you know where that is configured? And can it be changed? According to https://www.kernel.org/doc/html/latest/process/programming-language.html (posted earlier) the kernel is gnu11 now, so I wouldn't expect there to be any problems upversioning out switches. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
The kernel switched to GNU11 with 5.18. RTAI is still 4.19 and 5.4, meaning all kernel space needs to be gnu89: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Makefile?h=linux-4.19.y=dd5638bc06a6bf3f5ca1a134960911dc49484386#n375 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Makefile?h=linux-4.19.y=dd5638bc06a6bf3f5ca1a134960911dc49484386#n445 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Makefile?h=linux-5.4.y=0c2544add9fc25c0e54a2167d6a2cfd2e696cf58#n412 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Makefile?h=linux-5.4.y=0c2544add9fc25c0e54a2167d6a2cfd2e696cf58#n487 https://www.phoronix.com/news/Linux-5.18-Does-C11 LinuxCNC may set -std=gnu11 however that covers userspace only (i.e. PREEMPT_RT builds.) All kernel modules are still gnu89. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Mon, 18 Sept 2023 at 13:40, Rene Hopf via Emc-developers wrote: > linux kernel uses gnu11, and so should we. > https://www.kernel.org/doc/html/latest/process/programming-language.html Everywhere I can find std= on github it is gnu11. But I sometimes see that error message above, and think that this might be when I am compiling for RTAI. I may need to reboot to the RTAI kernel, reconfigure and then see what the generated files have. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On 18.09.23 13:14, andy pugh wrote: On Sun, 17 Sept 2023 at 02:48, Alec Ari via Emc-developers wrote: hal/components/limit_axis.comp:67:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode Is there a good reason for the RTAI config to force C90 (?) mode? I looked for where this happens a bit ago and didn't find it. linux kernel uses gnu11, and so should we. https://www.kernel.org/doc/html/latest/process/programming-language.html ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
On Sun, 17 Sept 2023 at 02:48, Alec Ari via Emc-developers wrote: > hal/components/limit_axis.comp:67:3: error: ‘for’ loop initial declarations > are only allowed in C99 or C11 mode Is there a good reason for the RTAI config to force C90 (?) mode? I looked for where this happens a bit ago and didn't find it. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
Meant to say, if you set CONFIG_FRAME_WARN to 0, the last error I posted should go away. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI broken again with LinuxCNC
What's really odd is that src/objects/hal/components/raster.c:14:10: fatal error: stdlib.h: No such file or directory stdlib.h is part of the C library, it shouldn't be looking for stdlib.h in kernel space, at all, ever. Alec ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
