Reportedly, pncconf does not work on preempt-rt because hal.kernel_version does not exist

[jepler]

see thread at https://forum.linuxcnc.org/forum/39-pncconf/30751-problems-with-prempt-rt-kernel-error-and-7i76e?limitstart=0

Using PNCconf: I can't use the test / tune functions for any axis motor or the spindle. I get the following error when trying to tune either axis stepper drive from within PNCconf:

File "/usr/bin/pncconf", Line 1630, in check_for_rt
eLif Hal.is_rt and not hal.kernel_version == actual_kernel:
AttributeError: 'module" object has no attribute 'kernel_version'

I did not test this for myself, but I think it's an accurate bug report that will affect any uspace user.

[jepler]

@c-morley can you take a look at this?

[c-morley]

I will try to look at it this weekend

Chris

---

From: Jeff Epler notifications@github.com
Sent: September 6, 2016 4:07 PM
To: LinuxCNC/linuxcnc
Cc: c-morley; Mention
Subject: Re: [LinuxCNC/linuxcnc] Reportedly, pncconf does not work on preempt-rt because hal.kernel_version does not exist (#159)

@c-morleyhttps://github.com/c-morley can you take a look at this?

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/159#issuecomment-245001464, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AHBrNTRn0qNnip4vcaVmbbTGgV8YofaBks5qnY-tgaJpZM4J1WQn.

[c-morley]

I did not get time to look into this, but looking at the error message it seems that the python module linuxcnc, with preempt_rt doesn't have kernal_version as an attribute:
AttributeError: 'module" object has no attribute 'kernel_version'

I assume this might be because there is no hard requirement for kernel version?
Maybe we could just have it report the current kernel version so the test passes?

Chris M

[jepler]

Yes, uspace realtime is not tied to one specific kernel, so that is why I coded it so that hal.kernel_version is not defined unless RTAPI_KERNEL_VERSION is (see commit 2c5ed60 "let python know the required kernel version"):

#ifdef RTAPI_KERNEL_VERSION
    PyModule_AddStringConstant(m, "kernel_version", RTAPI_KERNEL_VERSION);
#endif

In 2.7, uspace is realtime with "any RT-Preempt kernel". In 2.8, this will depend on compile-time configuration details AND runtime installed packages besides the kernel. For instance, I could write something like this:

#ifdef RTAPI_KERNEL_VERSION
    PyModule_AddStringConstant(m, "kernel_version", RTAPI_KERNEL_VERSION);
#else
    if(rtapi_is_realtime())
    {
        uname(&uts);
        PyModule_AddStringConstant(m, "kernel_version", uts.release);
    }
    else
    {
        PyModule_AddStringConstant(m, "kernel_version",
            "Any RT-Preempt kernel"
#ifdef USPACE_RTAI
            " or any RTAI kernel with LXRT support"
#endif
#ifdef USPACE_XENOMAI
            " or any Xenomai kernel with posix skin support"
        );
    }
#endif

pncconf and stepconf are the two in-tree users of hal.kernel_version so I am open to doing whatever makes more sense: changing those program so they don't query hal.kernel_version except when rtapi_is_kernelspace(), or changing our promise so that hal.kernel_version is always defined to something, if we can define what that something should be.

[c-morley]

I think we should make hal.kernal_version always defined to something.
If it makes sense in preempt to make it display the current kernel ( because for instance the current kernel will always work) then that seems fine.
Pncconf and stepconf only really want to know if using the HAL system is valid at the time of test invocation and give a hint to the user if not. With kernal RTAI the kernel had to be right or the system failed badly.
We could add a HAL_SYSTEM_AVAILABLE test in the hal module that could test in whatever way is required (now or in the future) for what ever realtime system is currently being used.
This would seem to future proof the problem alot and leave the problem in one place.

Chris M