[erlang-questions] Generating skeleton linked-in driver code using an IDL?
Fri Mar 6 10:18:28 CET 2009
Jani, it sounds like you're the wrong bacekend. IC re-use the OMG IDL
C-mapping when generating code for Erlang-C-communication, which doesn't
require using Orber and an external C/C++ ORB. Judging by your
description, you didn't supply the correct back-end options. You should
use erl_genserv and c_server.
If no back-end option is defined, the default value erl_corba is used.
Then you need another ORB. You can also try erl_template back-end. Its
main purpose is to be used together with erl_corba, but shows how a
call-back module for erl_genserv can be implemented (e.g. dealing with
oneway, inout, out etc).
Niclas @ Erlang/OTP
On Fri, 6 Mar 2009, Kenneth Lundin wrote:
> 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 <>:
>> 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 18.104.22.168 has mailed to spamtraps here'.)
>> erlang-questions mailing list
> erlang-questions mailing list
More information about the erlang-questions