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

[Niclas Eklund]

Hello!

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).

Best regards,

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 <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
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>