Dialogic device driver

Dialogic device driver

Post by Lars Pete » Sun, 02 Jul 1995 04:00:00



Our company is considering to port the device drivers for Dialogic
voice/voice recognition boards to Linux. We will have the source
code for the SCO version of the driver, the trouble is we don't
really know much about device drivers under Unix. Is there any
literature/howto document available for this purpose ? I mean
something like "How to write a device driver under Linux", and how
to create loadable modules.

This is an interesting project, if all goes well, we will be
shipping unattended mission-critical voice processing machines
running under Linux.
As far as I know, this is the biggest commercial project ever
done with Linux, and is going to change Linux' reputation in
regard to commercial use considerably.

"We trust it!"

-lp

--

``The mail must flow on''          |  Duesseldorf, FRG +49-211-5580532 (data)

 
 
 

Dialogic device driver

Post by Joe Portm » Fri, 07 Jul 1995 04:00:00


: Our company is considering to port the device drivers for Dialogic
: voice/voice recognition boards to Linux. We will have the source
: code for the SCO version of the driver, the trouble is we don't
: really know much about device drivers under Unix. Is there any
: literature/howto document available for this purpose ? I mean
: something like "How to write a device driver under Linux", and how
: to create loadable modules.

I ported our (Westin Hotels & Resorts) version of the Dialogic VM driver
to Linux well over a year ago. Only corporate resistance kept them from
shipping running linux systems instead of SCO Xenix 386.

In general, writing the driver was an interesting but not difficult
challenge.

Some things to look out for:

splx and friends do not exist. But, the good news is, you don't need them.
I only had to wrap a very few mission critical lines of code inside the
cli and sti handlers.

Sleep and wakeup have TOTALLY different semantics. IN Unix, sleep takes
an address and a priority. In Linux, sleep_on and sleep_on_interruptible
take a wait queue pointer.

Memory mapping and friends are not needed. You don't have to physmap and
so forth, just point at the memory segment you want directly. Very nice,
and makes driver debugging very easy.

Another note:
If at all possible, design your driver as a loadable module from the
start. This really speeds development. I was able to finish the port in
about 10 working days, due to the fact that I did not have to recompile
the kernel and reboot between tests.

Took only two more days to port the entire voice mail system, IE the
mailbox handling code, the PBX interfaces the inband and outband
signalling, etc... About 65 Megabytes of source.

: This is an interesting project, if all goes well, we will be
: shipping unattended mission-critical voice processing machines
: running under Linux.
: As far as I know, this is the biggest commercial project ever
: done with Linux, and is going to change Linux' reputation in
: regard to commercial use considerably.

: "We trust it!"

So do we, :-) Just make sure you include some kind of remote reboot
capability or a watchdog timer. NOTHING runs perfectly. :-)
--
-----------------------------------------------------------------------------
Joe Portman - Alternate Access Inc.             Affordable, Reliable Internet
        For questions or support, call our voice line (206) 728-8595.
-----------------------------------------------------------------------------

 
 
 

1. Device driver calling another device driver.

Hi.

I am having a problem writing a "meta-driver", ie one that is sandwiched
between the kernel and a real device driver. The platform I am using
consists of a Sun IPC, running SunOS 4.1.1.

My problem is that in attempting to use the OPEN(2V) system call from within
the "xxopen" routine of my metadriver (to open another device-driver (which
then opens the device)); OPEN(2V) "fails".

It appears that calling OPEN(2V) from within the kernel requires a different
calling sequence and argument list. Viz-a-viz: instead of a file descriptor
being returned by OPEN(2V), it seems a pointer is returned (which itself is
a pointer to something else).

Is this true? Is the OPEN(2V) syscall different for a process executing in
user address space, compared to the OPEN call executed by a process running
in kernel mode/address space?

If this is true for OPEN, what about CLOSE, READ, WRITE, etc? Unfortunately,
I don't have (easy) access to any Unix (source) code, to verify this.

Thanks in advance for help/advice.

2. sunfire 4800

3. Device driver question (generic device driver)

4. Adress apache via LAN

5. Drivers for Dialogic D21D

6. Help ME!

7. *** DIALOGIC TELEPHONY BOARDS DRIVERS

8. ipchains / ICQ question

9. Do Dialogic drivers work under Linux? (telephony)

10. Need help with Dialogic D40 B Drivers

11. dialogic drivers and H323 app

12. Drivers for Dialogic ?

13. Need Linux Dialogic ProLine2/V driver