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

[Kenneth Lundin]

Hi Jani,

The IDL compiler (IC) in the Erlang/OTP release already has support
for generating the Erlang side and
the C side including serialization to the Erlang external format.


This is used for communcation between Erlang-nodes and so called
C-nodes implemnted with help of the erl_interface/ei libraries.
When used like this there is absolutely no CORBA involved.

Unfortunately it does not have support for generating the Erlang and C
side of a driver but it would not be a very big job to add that as an
additional backend.

/Kenneth Erlang/OTP, Ericsson

2009/3/5 Jani Hakala <jjhakala@REDACTED>:
> 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'.)
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>