Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 11 Jul 2008 11:22:37 -0500

Hi Ben,

On Tuesday 08 July 2008 19:54:29 Ben Franksen wrote:
>
> The problem might be solved by suitable generalization. I am thinking about
> extensible syntax with pluggable handlers, an idea I've been pondering for
> a long time. This would have a wide range of possible applications,
> including pluggable field properties like 'copy_to_partner' as proposed by
> Bernd, while retaining complete backward compatibility. Let me explain what
> I mean.

Funny, a pluggable parser is one of my plans for the future, although there 
are a number of other major jobs that need doing first.  We actually need two 
separate parsers since the IOC isn't going to be reading DBD files in the 
future, all that information will be compiled into the generated binary.

The DBD files will still be needed though, they provide the meta-data for the 
DB files, and any plugin for a DB file parser must be described somehow in a 
DBD file to allow VDCT to understand and generate the DB file.  This is 
slightly contrary to your "unspoken assumption" about the parser ignoring 
items it doesn't understand — DBD files must declare all of the information 
needed to parse DB files so that generic tools like VDCT can understand and 
create them properly.

Parsing of DBD files (record, device, driver, menu, registrar, function and 
variable definitions) will be done at compile time using Perl code that 
already exists (at this stage we're mostly just doing text manipulation and 
generating C code from the DBD descriptions, so Perl is much more efficient 
than writing it in C).  Breaktables will be read at runtime from DB files and 
are ideal for pluggable interpretation on the IOC.

Unfortunately Bernd needs to add information to the field descriptions which 
get converted to C structures.  This may have to be incorporated before Base 
gets built, although it might be feasible to implement something like the 
generic info items into the record field descriptors — that should be 
sufficient for his purposes.

> Currently all syntax for db and dbd files is hard-coded into the parser.
> That, however, need not be the case. The grammar itself is very simple and
> regular: there is exactly one aggregate syntactical structure which I will
> call <definition>. A definition consists of a <head> of the form:
>
> 	<keyword> (<argument>,...)
>
> optionally followed by a <body>:
>
> 	{ <definition> ... }
>
> where an <argument> is either a number, or a quoted string (unrestricted
> charset), or a bareword (restricted charset). The top-level is simply a
> sequence of definitions (like the inside of a body).

With one exception: the body of a breaktable currently comprises a free-form 
list of raw+converted number pairs, space or comma separated.  I'm planning 
to change that syntax in R3.15 to match the above scheme, using the 
keyword "point" with two arguments.

I don't have time to comment further now, and I'll be on vacation all next 
week.  However I would be very interested in help writing a pluggable DB file 
parser; feel free to think about the new DBD file syntax that describes DB 
parser plugins...

- Andrew
-- 
Talk is cheap. Show me the code. -- Linus Torvalds

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System