Date: Mon, 21 Oct 1996 17:06:39 +0200 From: Poul-Henning Kamp <phk@critter.tfs.com> To: Garrett Wollman <wollman@lcs.mit.edu> Cc: Mikael Karpberg <karpen@ocean.campus.luth.se>, current@FreeBSD.org Subject: Re: ISDN code removal, final warning. Message-ID: <1935.845910399@critter.tfs.com> In-Reply-To: Your message of "Mon, 21 Oct 1996 10:25:18 EDT." <9610211425.AA12165@halloran-eldar.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>As for the original question of ISDN: probably there needs to be some >in-kernel support for the basic data-transfer functions. All of the >signalling, however, should be done outside of the kernel. If this >means you have to introduce a new isdnsrvr() system call, so be it. >(Although I would prefer a generic kernel-user message-passing >interface modeled along the lines of PF_ROUTE and PF_KEY, only >completely general. Then it could be used to eliminate such things as >/dev/klog.) I agree that putting all the Q931 in userland is a good idea, if nothing else, then for the developers of it. I think I would want to see the kernel driver for a ISDN card reduced to: /dev/isdn%dd D-channel. The kernel implements LAP-D and the interface to userland is packets. /dev/isdn%db%d B-channel. Depending on the negotiation you either get the contents of HDLC frames or raw bytes. Everything else can be done with the existing interfaces we have: pty, tun, raw sockets &c &c. This would be a nice starting point for working with ISDN. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1935.845910399>