Support new link types

[mdavidsaver]

I'd like to use this ticket to track the progress of work (primarily Andrew's) to allow the addition of new types of links in the process database.

[mdavidsaver (mdavidsaver)]

Andrew says:

Still needed:
* Move text parsing code into individual link support files
* Add ability to register new link support types
* Consider whether processNotify could/should be included here too

Do you plan to introduce new link type codes? All the src/std/dev/dev*.c would need to be updated to not treat this as an error, and I can see that motorRecord would as well (I'm surprised I couldn't find more). Another option would be to overload the meaning of CA_LINK.

In either case, it seems not too much additional work once the link syntax is defined.

[Andrew Johnson (anj)]

I would like to avoid adding new link type codes; I wonder if we could re-purpose the existing codes to indicate characteristics of the link type to the record support instead of defining the link provider: CA_LINK could become a synonym for REMOTE_LINK (indicating that the return value from dbIsLinkConnected() might change over time), DB_LINK might become LOCAL_LINK and indicate lockset joining, while CONSTANT might stay pretty much the same (although we could have more than one implementation of CONSTANT links).

Parsing becomes a bit more tricky, when should it happen? Currently we parse links in dbStatic at load time, but a registered parser might not be available until iocInit time, so can we move the parsing to then? That may be possible since we already store the raw text, but I'm not sure what the other implications might be of that — hopefully you (Michael) may have some insight there since you've already worked on the link parser.

I was considering adding a new link syntax for the new parser stuff; I think we might be able to allow a leading '{' to switch to that, at which point something like JSON would work, although I really wish the keys didn't have to be quoted. We could bastardize our JSON parser to allow unquoted keys as long as they're ASCII (following C identifier rules say) but I realize that might be a bad idea. While we're upgrading the link syntax, I'd also like to reserve a leading '[' to allow array constants, but that doesn't solve the issue that array field storage is currently allocated by the record type code at record-init.

The point of my question about adding the processNotify API to the LSET is so we could simplify the dev*iSoftCallback.c support and maybe even completely remove the PN_LINK type again. We could then remove many of the plink->type checks in std/dev and add DB-link put-notify support for the output record types (we could do that now with PN support, I believe it just needs to be added to the device support code).