hal: Make HAL mutex recursive and use acquire/release functions

[BsAtHome]

Change the HAL mutex from a simple mutex to a recursive mutex. This is necessary to support coming changes in the HAL API.

Many changes in the PR are simply to replace the old mutex get/give with a halpr_mutex_acquire/halpr_mutex_release call. This is actually a hal_lib private API, but removing access to hal_priv.h would require a huge change-set. This way it will be done gradually.
The forced mutex release function (used in halcmd) is now part of hal_lib so that the caller no longer needs to access library internals. Anyway, when you need to force-release the mutex, then all bets are off and you should restart anyway.

The rtapi_app is now cleared of accessing the HAL private API. The newinst code (if anybody is using it) now uses a call into a specially published hal_lib function to call the constructor instead of extracting a halpr_xxx function.
The has been postponed because it changes a prototype that may give a problem. However, it is unlikely that anyone is using constructable components since this is (already since 2.2) an experimental feature.

[grandixximo]

Also, at src/hal/utils/halcompile.g:549:

The typedef gained const, but halcompile still emits static int export_1(char *prefix, char *argstr). Out-of-tree constructable comps will warn (C) or fail (C++) against the new header. Suggest emitting const char * here and at the registration site (line 679 is fine as-is).

Should it be fixed here, or keeping that for later?

[BsAtHome]

The typedef gained const, but halcompile still emits static int export_1(char *prefix, char *argstr). Out-of-tree constructable comps will warn (C) or fail (C++) against the new header. Suggest emitting const char * here and at the registration site (line 679 is fine as-is).

Should it be fixed here, or keeping that for later?

This is a such a damned if you do, damned if you don't case... The whole constructable component stuff has been experimental for ages and I have never seen an instance where it is used. No in-tree component uses it and wonder if out-of-tree knows it exists. Changing it risks breaking stuff that is a fringe use from the past. Leaving it as is means some things can not be properly isolated.

The constructable option is not documented in halcompile and the newinst command in halcmd cannot process it (it is embedded i a #if 0). Only rtapi_app knows about it.

Probably need to ask on the dev-list if this is used by anybody.

[grandixximo]

Ok, are you sending an email up to the ML?
On hold till we get a reply? Or merge as is since I think you are not touching it now if I'm not wrong...

[BsAtHome]

Ok, are you sending an email up to the ML?

Yes, just writing it.

On hold till we get a reply? Or merge as is since I think you are not touching it now if I'm not wrong...

I took it out so this can get merged without further delay. The constructable/newinst stuff is not paramount to the progression. Just added a FIXME so it gets cleaned up later.

[grandixximo]

Only found one real user on github gwassem/linuxcnc_sim , but his code is broken, I think based on machinekit (where newinst actually works and is used) posted an issue there about it.
After having done a quick search of newinst and since I found it used only once, I doubt we'll get anything back from the mailing list.