From owner-freebsd-hackers  Wed Nov 27 17:26:41 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id RAA27448
          for hackers-outgoing; Wed, 27 Nov 1996 17:26:41 -0800 (PST)
Received: from rocket.comtrol.com (rocket.comtrol.com [204.73.219.5])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA27443
          for <hackers@freebsd.org>; Wed, 27 Nov 1996 17:26:38 -0800 (PST)
Received: from amirpc (amir [204.73.219.82]) by rocket.comtrol.com (8.6.9/8.6.9) with SMTP id TAA13944 for <hackers@freebsd.org>; Wed, 27 Nov 1996 19:26:07 -0600
Date: Wed, 27 Nov 1996 19:26:07 -0600
Message-Id: <199611280126.TAA13944@rocket.comtrol.com>
X-Sender: amir@comtrol.com
X-Mailer: Windows Eudora Version 2.0.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hackers@freebsd.org
From: amir@comtrol.com (Amir Farah)
Subject: isdn
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>To: hackers@freebsd.com
>From: amir@comtrol.com (Amir Farah)
>Subject: isdn
>
>Hi
>
>Here is one everyone can chew on over thanksgiving:
>
>I have an ISDN board along with software from LINK TECHNOLOGY which
provides layers 1 to 3 for an ISDN board. I was able to implement layer 4 as
a driver in FreeBSD 2.1 and invoke layers 1 to 3 from the LINK software. The
Link software sees the board and configures the directory # and spid # I
provided. I could code a number and spid for an outgoing call and the LINK
software would do it for me. The problem is: how to write the driver to
support ppp (which is all I want to do at this point). Eventually multi-link
ppp.......... 
>
>I looked at "an intermediate level for ISDN drivers" just now, the file
isdn.c in /sys/gnu/isdn, and thought of the following approach:
>
>I could write a driver that makes calls to routines in
/sys/gnu/isdn/iitty.c for a tty layer and replace the file isdn.c with my
own interface which builds commands for the LINK software. LINK would then
handle call setup and data transfers between the driver and the isdn board.
Does that sound like a sane approach and is this the sort of situation that
the routines in /sys/gnu/isdn were designed for??
>
>amir
>