10 messages in org.freebsd.freebsd-isdnRe: i4b and netgraph (was: I4B suppor...| From | Sent On | Attachments |
|---|---|---|
| Hellmuth Michaelis | Jan 28, 1999 1:23 am | |
| Barry Scott | Jan 28, 1999 3:40 am | |
| Archie Cobbs | Jan 28, 1999 12:01 pm | |
| Archie Cobbs | Jan 28, 1999 12:09 pm | |
| Hellmuth Michaelis | Jan 28, 1999 1:07 pm | |
| Archie Cobbs | Jan 28, 1999 1:15 pm | |
| Julian Elischer | Jan 28, 1999 2:27 pm | |
| Barry Scott | Jan 29, 1999 2:47 am | |
| Jos Backus | Jan 29, 1999 8:53 am | |
| Julian Elischer | Jan 29, 1999 9:25 am |
| Subject: | Re: i4b and netgraph (was: I4B support for US ISDN?) | |
|---|---|---|
| From: | Archie Cobbs (arc...@whistle.com) | |
| Date: | Jan 28, 1999 12:09:15 pm | |
| List: | org.freebsd.freebsd-isdn | |
Hellmuth Michaelis writes:
- as long as netgraph is not a standard part of FreeBSD i don't think its a good idea to move i4b to netgraph.
We hope it will become standard someday...
- currently, i4b is relatively self-contained and runs under all BSD's (i've got even BSD/OS patches for it). Going to netgraph seems to imply a then necessary namechange from isdn4bsd to isdn4freebsd (or to package netgraph into the i4b distribution which i don't like at all).
Becoming netgraph compatible does not imply losing the ability to run in normal mode... doing this would imply some #ifdef NETGRAPH conditional code though.
- as far as i understood the netgraph docs, they also use function calls and _no_ message queues for interlayer communication. So going to netgraph would not solve the mentioned problem. BTW: i once asked Terry about the queue/function tradeoffs when that was discussed on the mailinglist and got no reply.
This is incorrect -- netgraph supports queueing.
- The ISDN model has a LME (layer management entity) connected to all layers using a different path to communicate than the interlayer communication mechanism, and i learned that implementing this is a must. I don't see how this is being done using netgraph.
The LME would send and receive the appropriate control messgages to each of the nodes.
- More, i currently don't see how the isdnd's functionality is brought to netgraph.
I'm unfamiliar with what isdnd does.. but there's nothing in netgraph that you couldn't do from a user mode daemon if you needed or wanted to.
- To my astonishment, i have read in the netgraph docs that Whistle plans to netgraph-enable the i4b ISDN driver code; i wasn't aware of that yet since Whistle seem to have its own ISDN stack and wasn't interested in i4b any longer after a short period of interest long time ago.
That wording is misleading.. we don't have any plans to convert i4b. What I meant was that it would make for a nice project. I'll change the wording.
- The last thing i personally need are 2 versions of i4b, one netgraphized and one not netgraphized.
I don't blame you there :-) Though the differences could be localized to a few key macros. The message based architecture of ISDN and the graph nature of netgraph are very similar.
- There is much more to to do to functionally enhance i4b, to make it more robust and to fix some bugs in it and i don't have an idea if net- graphizing i4b brings us more forward with these issues since my time budget is clearly limited.
In a word, i'm a bit sceptical.
I respect your priorities.
I think a netgraph version of ISDN would be nice, time and motivation permitting. I'm not really arguing anything stronger than that.
-Archie
___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message