ose: Remove all code related to the OSE port

The OSE port is no longer supported and this commit removed it
and any changes related to it. The things that were general
improvements have been left in the code.

1 files changed, 0 insertions, 240 deletions

diff --git a/lib/ose/doc/src/ose_signals_chapter.xml b/lib/ose/doc/src/ose_signals_chapter.xml
deleted file mode 100644
index bcf2259577..0000000000
--- a/lib/ose/doc/src/ose_signals_chapter.xml
+++ /dev/null
@@ -1,240 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
-  <header>
-    <copyright>
-      <year>2013</year><year>2014</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-
-    </legalnotice>
-
-    <title>Interacting with Enea OSE</title>
-    <prepared>Lukas Larsson</prepared>
-    <docno></docno>
-    <date>2014-01-08</date>
-    <rev>A</rev>
-    <file>ose_signals_chapter.xml</file>
-  </header>
-
-  <marker id="introduction"></marker>
-  <section>
-    <title>Introduction</title>
-    <p>The main way which programs on Enea OSE interact is through the
-    usage of message passing, much the same way as Erlang processes
-    communicate. There are two ways in which an Erlang programmer can
-    interact with the signals sent from other Enea OSE processes; either
-    through the provided <c>ose</c> module, or by writing a custom linked-in
-    driver. This User's Guide describes and provides examples for both
-    approaches.
-    </p>
-  </section>
-
-  <marker id="erlang"></marker>
-  <section>
-    <title>Signals in Erlang</title>
-    <p>Erlang/OTP on OSE provides a erlang module called
-    <seealso marker="ose:ose">ose</seealso> that can be used to interact
-    with other OSE processes using message passing. The api in the module
-    is very similar to the native OSE api, so for details of how the
-    functions work please refer to the official OSE documenation. Below
-    is an example usage of the API.
-    </p>
-    <code>1> P1 = ose:open("p1").
-#Port&gt;0.344>
-2> ose:hunt(P1,"p2").
-{#Port&gt;0.344>,1}
-3> P2 = ose:open("p2").
-#Port&gt;0.355>
-4> flush().
-Shell got {mailbox_up,#Port&gt;0.344>,{#Port&gt;0.344>,1},852189}
-ok
-5> ose:listen(P1,[1234]).
-ok
-6> ose:send(P2,ose:get_id(P1),1234,&gt;&gt;"hello">>).
-ok
-7> flush().
-Shell got {message,#Port&gt;0.344>,{852189,1245316,1234,&gt;&gt;"hello">>}}
-ok</code>
-  </section>
-
-  <marker id="driver"></marker>
-  <section>
-    <title>Signals in a Linked-in driver</title>
-    <p>
-      Writing Linked-in drivers for OSE is very similar to how it is done
-      for Unix/Windows. It is only the way in which the driver subscribes
-      and consumed external events that is different. In Unix (and Windows)
-      file descriptiors (and Event Objects) are used to select on. On OSE
-      we use signals to deliver the same functionality. There are two large
-      differences between a signal and an fd.
-    </p>
-    <p>
-      In OSE it is not possible for a signal number to be a unique identifier
-      for a resource in the same way as an fd is. For example; let's say we
-      implement a driver that does an asynchronous hunt that uses signal
-      number 1234 as the hunt_sig. If we want to be able to have multiple
-      hunt ports running at the same time we have to have someway of routing
-      the signal to the correct port. This is achieved by supplying a secondary
-      id that can be retrieved through the meta-data or payload of the signal,
-      e.g:
-      <code>ErlDrvEvent event = erl_drv_ose_event_alloc(1234,port,resolver);</code>
-      The event you get back from
-      <seealso marker="ose_erl_driver#erl_drv_ose_event_alloc">
-      erl_drv_ose_event_alloc</seealso> can then be used by
-      <seealso marker="erts:erl_driver#driver_select">driver_select</seealso>
-      to subscribe to signals. The first argument is just the signal number
-      that we are interested in. The second is the id that we choose to use,
-      in this case the port id that we got in the
-      <seealso marker="erts:driver_entry#start">start</seealso> callback is
-      used. The third argument is a function pointer to a function that can
-      be used to figure out the id from a given signal. The fourth argument can
-      point to any additional data you might want to associate with the event.
-      There is a complete. You can examine the data contained in the event with
-      <seealso marker="ose_erl_driver#erl_drv_ose_event_fetch">erl_drv_ose_event_fetch</seealso>
-      , eg:
-      <code>erl_drv_ose_event_fetch(event, &amp;signal, &amp;port, (void **)&amp;extra);</code>
-      example of what this could look like in
-      <seealso marker="#example">the next section</seealso>.
-      <note>It is very important to issue the driver_select call before
-      any of the signals you are interested in are sent. If driver_select
-      is called after the signal is sent, there is a high probability that it
-      will be lost.</note>
-    </p>
-    <p>
-      The other difference from unix is that in OSE the payload of the event
-      (i.e. the signal data) is already received when the ready_output/input
-      callbacks are called. This means that you access the data of a signal
-      by calling <seealso marker="ose_erl_driver#erl_drv_ose_get_signal">
-      erl_drv_ose_get_signal</seealso>. Additionally multiple signals might be
-      associated with the event, so you should call
-      <seealso marker="ose_erl_driver#erl_drv_ose_get_signal">
-      erl_drv_ose_get_signal</seealso> until <c>NULL</c> is returned.
-    </p>
-  </section>
-
-  <marker id="example"></marker>
-  <section>
-    <title>Example Linked-in driver</title>
-<code>#include "erl_driver.h"
-#include "ose.h"
-
-struct huntsig {
-  SIGSELECT signo;
-  ErlDrvPort port;
-};
-
-union SIGNAL {
-  SIGSELECT signo;
-  struct huntsig;
-}
-
-/* Here we have to get the id from the signal. In this case we use the
-   port id since we have control over the data structure of the signal.
-   It is however possible to use anything in here. The only restriction
-   is that the same id has to be used for all signals of the same number.*/
-ErlDrvOseEventId resolver(union SIGNAL *sig) {
-  return (ErlDrvOseEventId)sig->huntsig.port;
-}
-
-static int drv_init(void) { return 0; };
-
-static ErlDrvData drv_start(ErlDrvPort port, char *command) {
-  return (ErlDrvData)port;
-}
-
-static ErlDrvSSizeT control(ErlDrvData driver_data, unsigned int cmd,
-                            char *buf, ErlDrvSizeT len,
-                            char **rbuf, ErlDrvSizeT rlen) {
-  ErlDrvPort port = (ErlDrvPort)driver_data;
-
-  /* An example of extra data to associate with the event */
-  char *extra_data = driver_alloc(80);
-  snprintf("extra_data, "Event, sig_no: 1234, and port: %d", port);
-
-  /* Create a new event to select on */
-  ErlDrvOseEvent evt = erl_drv_ose_event_alloc(1234,port,resolver, extra_data);
-
-  /* Make sure to do the select call _BEFORE_ the signal arrives.
-     The signal might get lost if the hunt call is done before the
-     select. */
-  driver_select(port,evt,ERL_DRV_READ|ERL_DRV_USE,1);
-
-  union SIGNAL *sig = alloc(sizeof(union SIGNAL),1234);
-  sig->huntsig.port = port;
-  hunt("testprocess",0,NULL,&amp;sig);
-  return 0;
-}
-
-static void ready_input(ErlDrvData driver_data, ErlDrvEvent evt) {
-  char *extra_data;
-  /* Get the first signal payload from the event */
-  union SIGNAL *sig = erl_drv_ose_get_signal(evt);
-  ErlDrvPort port = (ErlDrvPort)driver_data;
-  while (sig != NULL) {
-    if (sig->signo == 1234) {
-      /* Print out the string we added as the extra parameter */
-      erl_drv_ose_event_fetch(evt, NULL, NULL, (void **)&amp;extra_data);
-      printf("We've received: %s\n", extra_data);
-
-      /* If it is our signal we send a message with the sender of the signal
-         to the controlling erlang process */
-      ErlDrvTermData reply[] = { ERL_DRV_UINT, (ErlDrvUInt)sender(&amp;sig) };
-      erl_drv_send_term(port,reply,sizeof(reply) / sizeof(reply[0]));
-    }
-
-    /* Cleanup the signal and deselect on the event.
-       Note that the event itself has to be free'd in the stop_select
-       callback. */
-    free_buf(&amp;sig);
-    driver_select(port,evt,ERL_DRV_READ|ERL_DRV_USE,0);
-
-    /* There could be more than one signal waiting in this event, so
-       we have to loop until sig == NULL */
-    sig = erl_drv_ose_get_signal(evt);
-  }
-}
-
-static void stop_select(ErlDrvEvent event, void *reserved)
-{
-  /* Free the extra_data */
-  erl_drv_ose_event_fetch(evt, NULL, NULL, (void **)&amp;extra_data);
-  driver_free(extra_data);
-
-  /* Free the event itself */
-  erl_drv_ose_event_free(event);
-}
-
-/**
- * Setup the driver entry for the Erlang runtime
- **/
-ErlDrvEntry ose_signal_driver_entry = {
-  .init                         = drv_init,
-  .start                        = drv_start,
-  .stop                         = drv_stop,
-  .ready_input                  = ready_input,
-  .driver_name                  = DRIVER_NAME,
-  .control                      = control,
-  .extended_marker              = ERL_DRV_EXTENDED_MARKER,
-  .major_version                = ERL_DRV_EXTENDED_MAJOR_VERSION,
-  .minor_version                = ERL_DRV_EXTENDED_MINOR_VERSION,
-  .driver_flags                 = ERL_DRV_FLAG_USE_PORT_LOCKING,
-  .stop_select                  = stop_select
-};
-</code>
-  </section>
-
-</chapter>