From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 9 06:49:24 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A8FF1065675 for ; Sun, 9 Mar 2008 06:49:24 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outI.internet-mail-service.net (outI.internet-mail-service.net [216.240.47.232]) by mx1.freebsd.org (Postfix) with ESMTP id C62E88FC1B for ; Sun, 9 Mar 2008 06:49:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sat, 08 Mar 2008 22:49:23 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 3A8572D6012; Sat, 8 Mar 2008 22:49:22 -0800 (PST) Message-ID: <47D38879.6000102@elischer.org> Date: Sat, 08 Mar 2008 22:49:29 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "harti@freebsd.org >> Hartmut Brandt" References: <200803081133.02575.hselasky@c2i.net> <20080308171435.J88526@fledge.watson.org> <47D2E469.9030507@dlr.de> In-Reply-To: <47D2E469.9030507@dlr.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Robert Watson , Hans Petter Selasky Subject: Re: Documentation on writing a custom socket X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2008 06:49:24 -0000 Hartmut Brandt wrote: > Robert Watson wrote: >> >> On Sat, 8 Mar 2008, Hans Petter Selasky wrote: >> >>> I'm planning to create a new socket type in FreeBSD called AF_Q921, >>> which is to be used for ISDN telephony. Where do I find documentation >>> on how to implement a new socket in the kernel ? >> > > [SNIP] > >> that isn't connected to the protocol stack, or by using a device stack >> tied to Netgraph nodes. Could you tell us a bit more about what you're >> trying to do, and perhaps we can provide some useful pointers? For > > I want to jump in here about the netgraph stuff (this was the second > time a response talked about using netgraph). > > While developing the ATM signaling stack (this is Q.2931) it turned out, > that the netgraph notion of sending message around very rapidly became a > nightmare if you want correct error handling. The number of states in > Q.2931 (12 states) and the API node exploded to something like 30 or 40 > because of the asynchronuous nature of the communication between stack > layers and error handling. One example: To setup a connection you invoke > a SETUP request. Then you wait for something like CALL_PROCEEDING, > RELEASE_ACK or CONNECT_ACK. Unfortunately you also want to return an > error in the case something is wrong with the request itself (no memory, > bad parameters). So you add an extra message that just ACKs that the > SETUP is going to be handled by the stack or rejected because of some > error in it. With a normal function call based interface you would just > make the setup-request function return an error code. With netgraph > however you need to invent a new message, have additional states in the > consumer and the protocol. Not to talk about error handling when you > want to correctly handle errors like not beeing able to allocate that > same response message. > > Netgraph is very nice for data-flow oriented stuff. It is not so useful > to stack complicated protocol layers. If I'd write the signaling stack > from scratch, I'd probably collaps all the signalling into a single > netgraph node with a socket interface on the upper end. But then one may > as well just implement that as a 'normal' protocol, probably... While I'm very flattered that people have used netgraph for things such as these, and happy to see that it works, keep in mind that Netgraph was in fact written as a way to do "pluggable link level switching", and not really to implement whole protocol stacks. A secondary design goal was to allow to do rapid prototyping of protocols and stream transforming modules. The framework has however been used sometimes as just a way to configure, load and control modules that don't actually use the network side of netgraph at all. (e.g. ng_fec) and its ability to export a stream to userland for extra processing has been useful to some people. I'm not saying that you were wrong to use netgraph, just explaining for the record why it acts the way it does. Having said that, nothing is static. I and others who work with Netgraph are very open to any suggestions that make it more useful. Whether that includes new control mechanisms and feedback schemes, or what-ever, don't feel shy about asking us about the possibility of enhancing it. > > > harti > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"