[erlang-questions] Generating skeleton linked-in driver code using an IDL?

[Jani Hakala]

I have written a small linked-in driver that fortunately has only a
few different kind of messages passing between erlang code and driver
(driver_entry outputv, ready_input+driver_output_binary). It also
handles several operations issued by port_control() (decoding of data
using ei_decode_*). A big portion of the code is related to decoding
and encoding of the data although the messages are quite simple.

I have looked at some of the code generation tools that are supposed
to help developing linked-in drivers. They (ETDK, DryvErl and the
proposed Foreign Function Interface) seem to focus on how to call
C-functions. I would be more interested about a tool that could be
used to define message structures and operations supported by a
linked-in driver. Those operations would call C/C++ functions in a way
that would not be visible outside the driver (facade pattern).

An IDL compiler is included in OTP so I wrote a CORBA IDL file that
could be a starting point for a new version of my linked-in driver (or
C node perhaps) if it was possible to generate
  1) C/C++ code that could be used to (de)serialize the messages,
  2) C/C++ skeleton files for the driver,
  3) Erlang code that would (de)serialize messages using CDR encoding or
     erlang external format (or other solution), and
  4) Erlang skeleton files for the process that owns the port.

1) could be implemented using ei_decode/ei_encode functions.
In the case of port_command (3) might be just call to term_to_binary
after some sanity checks for the parameters. Most of the checking
could be delayed until the C-code deserializes the data.

ic - the erlang IDL compiler - generates several files that might be
useful if a tool supporting this kind of scheme was developed or if ic
was modified:
  - The output files include type codes that describe the data
    structures (:tc/0) and operations (:oe_get_interface/0).
  - Record definitions are also available for each defined structure
    and exception.
  - The names, in/inout/out information of the parameters are
    unfortunately not readily available (not without changing ic?).
  - No oneway-information for operations either.

A attached two files to this email: CAN.idl (which is nowhere close to being a
complete definition) and CAN.txt that contains some sort of use cases.

Jani Hakala

(Third attempt on sending this message... my other email address gets
complaints about
'Your address 130.234.4.43 has mailed to spamtraps here'.)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CAN.txt
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090305/50c24096/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CAN.idl
Type: application/octet-stream
Size: 1355 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090305/50c24096/attachment.obj>