Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 18 Aug 2014 12:06:24 -0500

On 08/18/2014 09:46 AM, Michael Davidsaver wrote:
>> Right now I am facing (reviewing) design documents of device support for 
>> a very versatile card that supports routing its inputs and outputs to a 
>> multitude of PCI/PCIe backplane signals. Stuff that cries for mbbi/mbbo 
>> type records that are not limited to 16 states. If option strings, 
>> values, severities were arrays, such records might be fairly easy to 
>> implement.
> 
> For the mrfioc2 driver I had to deal with this problem (as you may
> remember ;).  The workaround was to have three mbbi/o records and a
> combination of UNSV and IVOA to handle some of the ~30 possibilities in
> each mbbo.

The 16-state limitation comes from CA, not from the record types
themselves. The db_gr_enum and related types have MAX_ENUM_STATES
hard-coded to 16, so until they switch to pvAccess there's no way for
clients to know what the choice values beyond 15 mean without layering
another protocol on top of CA. Note that dbAccess has a different limit,
dbAccessDefs.h uses DB_MAX_CHOICES (defined as 30 in dbDefs.h) for its
enum strings limit, which is more easily changed since it isn't fixed in
any network protocol.

It would be feasible for a record type to have a string field that it
treats as an enum internally, using special() to reject bad choices and
to convert the string to an index kept in another field. The set of
legal choices would have to come from other fields though, possibly as
an array of strings (this is what I meant by layering another protocol
on top of CA).

>> Has extending the DB syntax to cover array data been considered at some 
>> point?

This will require a change to the record-type interface (RSET) because
currently it is the record's responsibility to allocate memory for its
array fields, which can't be done right now until iocInit().

> One of changes I'm considering (after the linking/locking work) is to
> re-write the DBD file parser.

The IOC doesn't really need a DBD file parser at all (although it will
still need a DB file parser), that was why I wrote the Perl DBD parser.
The record and field descriptions can be converted into tables in the
*Record.h files which will get compiled into the *Record.o binary
(currently we only do that for the field size and offset data). I
started that work some time back, and would like to finish it.

> The idea would be to parse into an intermediate structure which would be
> more general than dbStatic.  This would define points in the syntax for
> future expansion, and avoid some of the chicken and egg problems of the
> present code.
> 
> For this specific use case, the intermediate structure would provide an
> obvious place to keep the original field value text.  Of course this
> tracking could also be grafted on to dbRecordNode as the info() tags where.

I will explicitly point out the increased memory requirement to store
all the original DB field values as text. Also some of the issues with
the existing parser (the use of the dbmf allocator) were added to avoid
the VxWorks memory fragmentation problem, which goes away if we can
require a minimum of about VxWorks 6.6.

Those questions prompted my tech-talk posting just now, asking the
community to discuss minimum IOC requirements for the future. I'm not
going to allow just anyone to veto an upgrade in requirements, but we'll
have to see what the responses are.

- Andrew
-- 
Advertising may be described as the science of arresting the human
intelligence long enough to get money from it. -- Stephen Leacock

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System