Default DTYP can be changed by DBD file order

[Andrew Johnson]

Kay Kasemir reported:

I was always silently expecting that a record from a *.db file that doesn't specifically list the DTYP would default to "Soft Channel". Example:

record(ai, "XXX")
{
  field(INP, "SomeOtherRecord")
}
just works because the field DTYP="Soft Channel" is the default.

Now I notice that at least with R7.0.3.1, the default is not "Soft Channel" but whatever is listed first in the *.dbd file. If that file looks like this:

device(ai, CONSTANT, devAiSoft, "Soft Channel")
device(ai, INST_IO, devAiXXXX, "MyDeviceSupport")

then the default for an ai record DTYP is indeed "Soft Channel".

But if I put "MyDeviceSupport" on top, that becomes the default, as can happen when you change the order of XXX_DBD file entries in the Makefile.

[Andrew Johnson (anj)]

This happens because dbdExpand.pl now allows device support to be defined before the record type it refers to has been loaded, so if base.dbd isn't the first DBD file some other support can become the first device support entry for one of the base record types instead of Soft Channel, and hence become the default for records that don't explicitly set DTYP.

I have a fix, which is to have the IOC always insert a device named "Soft Channel" at the beginning of the device list (zeroth position) for the record type. This makes "Soft Channel" a special device name which it actually wasn't before, but this is about the only nice way I can see to resolve this.

My new code also aborts the parser if a new device support called "Soft Channel" is ever loaded after the record type already has record instances loaded.

[Andrew Johnson (anj)]

See https://github.com/epics-base/epics-base/pull/96 for my proposed fix.

[Andrew Johnson (anj)]

RL: Can the dbdExpand take a flag to allow the auto-declaration to not be an error, which CONFIG_SITE could set?

[Andrew Johnson (anj)]

I now realize that it's only registerRecordDeviceDriver.pl which should allow auto-declaration of record types; dbdExpand.pl should throw an error if the parser sees a device support reference to a record type that doesn't exist. This means no build-system flag should be required for building device support into a loadable module, which simplifies the fix to Perl code changes only.

I have closed the previous PR and created https://github.com/epics-base/epics-base/pull/112 with this approach instead.