Commit Graph

15 Commits

Author SHA1 Message Date
pooka
dae7af8b24 Ready the kernel side of i4b for primary rate interface support by
removing assumptions that there are only two B channels and by
adding support for a varying number of channels.

Due to this, rename previously used isdn identified "bri" to "isdnif",
which better describes the current situation.
2003-10-03 16:38:44 +00:00
pooka
0553a30d48 Make the number of maximum b-channels provided by a controller a macro
and base the calculation of the amount of call descriptors on that.

Define MAX_BCHAN as 2 for now, since we don't support primary rate (yet).
2003-09-25 15:16:08 +00:00
martin
4afabfd9b3 Cache a pointer to layer 3 driver state in a call descriptor.
Use this instead of expensive isdn_find_l3_by_bri() calls where possible.
2002-03-30 11:43:33 +00:00
martin
e14f4779db Avoid duplicate expensive lookups by passing a pointer to the call
descriptor/a pointer to the layer 3 state directly to driver functions,
instead of their ID/index.
2002-03-30 11:15:41 +00:00
martin
3ba8ce25ee Pass subaddresses and calling party number type/plan to userland on
incoming calls.
2002-03-30 07:08:13 +00:00
martin
f5e2c967fc Split BRI attaching into two phases, so lower layer drivers can get their
BRI identifier and L3 driver state early on, then finish initializing and
announce the controller to userland when it's ready.
2002-03-29 20:29:53 +00:00
martin
963ecd396e Plug a memory hole when detaching ISDN controllers. 2002-03-25 14:25:06 +00:00
martin
a994533d0a Make pcmcia cards detach properly.
Notify userland of attaching/detaching cards.
This partly fixes PR 15951.
2002-03-25 12:07:33 +00:00
martin
0bc69b6498 Now that we have all the pieces of the puzzle available start to unriddle
and move them in their proper places.

Move the BRI registry from layer 2 (duh!) to layer 4, so active cards
(which don't have layer 3 or layer 2 in their driver). Remove all remaining
hard coded controller and driver types. Remove any arbitrary hard coded
limits, at least those that show up in the internal API.

This fixes PR 15950.
2002-03-24 20:35:43 +00:00
martin
9cea4a0ab0 Bring the daic driver into the new ISDN world order.
Enable active card support in the ISDN subsystem. (Had been disabled since
it couldn't be tested before.)
2002-03-22 09:54:15 +00:00
martin
e2c42aeaa8 Remove all knowledge about specific application (layer 4) drivers from
the generic layer 4 and layer 3 management system.

This should make the layer 4 driver API LKM clean - finaly.

Make the Fritz!PCI driver work again after resent changes (oops!),
noted by Frank Kardel (PR 15948) and Matthias Scheeler.
2002-03-17 20:54:04 +00:00
martin
14a03255ac Remove the hard coded layer 4 driver coding from the accounting data
and functions, use the call ID instead.
2002-03-17 11:08:31 +00:00
martin
1e802e7eba Clean up the application (layer 4) driver vs. B channel driver interface.
One step further on the way to make layer 4 drivers LKMable.
2002-03-17 09:45:58 +00:00
martin
5171d409a5 First step to cleanup the hardware driver <-> upper layers interface.
This now provides slightly more functionality than the FreeBSD layer1-newbus
interface. It was meant to be a simple change to one header and a few
c files, but the change rippled all through various stuff.

To prevent a change to the kernel<->userland interface right now the kernel
is now lying about card types to userland (but who cares). This will be fixed
when the userland interface changes, after layer 3 <-> layer 4 has been
fixed.

Functional changes:

Provide a clean interface for hardware drivers to attach to the upper
layers. This will need another small change in the B-channel handling
when a similar change to the layer 3 <-> layer 4 interface happens.

Avoid passing indices into global arrays of pointers around, instead pass
the pointers itself. Don't code hardware driver types by predefined magic
numbers (think LKM). Prepare for detachable drivers (think pcmcia).

While there remove some sets of function pointers always pointing to the
same function (meant to be the configurable set of D channel protocol
handlers). It is unlikely another supported D-channel protocol will fit into
that (maximal layer interface) abstraction. When we get support for another
protocol, we will need to come up with a workable interface. Besides, the
old implementation was, uhm, strange.
2001-03-24 12:40:29 +00:00
martin
c3cb638bca Initial import of ISDN4BSD release 0.96 2001-01-05 12:49:52 +00:00