From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 21:31:17 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE05010656CC for ; Wed, 18 Feb 2009 21:31:17 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8CC7A8FC0C for ; Wed, 18 Feb 2009 21:31:17 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 842DB29A35C; Wed, 18 Feb 2009 16:11:49 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 18 Feb 2009 16:11:49 -0500 X-Sasl-enc: 4ic1MK/s/o781sdcB5dZNReOpgOwlvV6G9Fg3KgACwCO 1234991508 Received: from empiric.lon.incunabulum.net (unknown [81.168.51.182]) by mail.messagingengine.com (Postfix) with ESMTPSA id 5956D30B31; Wed, 18 Feb 2009 16:11:48 -0500 (EST) Message-ID: <499C7992.7000705@incunabulum.net> Date: Wed, 18 Feb 2009 21:11:46 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Ed Schouten References: <4999F7F9.4030204@elischer.org> <499A024A.60209@protected-networks.net> <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> <20090217115651.GE79178@hoeg.nl> <20090217175512.GG79178@hoeg.nl> <20090217182128.GH79178@hoeg.nl> <20090217192152.GI79178@hoeg.nl> In-Reply-To: <20090217192152.GI79178@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Butler , current@freebsd.org, Maksim Yevmenkin Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 21:31:18 -0000 Ed Schouten wrote: > ... > As you mentioned earlier, there is no need to use pts(4), because > rfcomm_sppd also supports using stdout/stdin. This is a lot better, > because our pipe implementation is probably a lot faster than pts(4). > I'd rather see the handbook changed to not mention TTYs anywhere. > > For what it's worth, rfcomm_sppd exists largely because up until now, mobile phone vendors have not implemented the BNEP profile in their hardware. Having to initiate a PPP session across a virtual serial port... to get to a PPP session over UMTS/GPRS... is just silly. It's not possible to roam even locally across a Bluetooth piconet to other providers with this sort of setup, as may be possible with BNEP in some situations. Also, if for whatever reason the local Bluetooth RFCOMM session is interrupted (phone rebooted, or interference in the ISM 2.4GHz band), due to the stateful nature of PPP, the connection can get torn down. BNEP doesn't have this issue, because it presents an Ethernet-like layer, and is therefore stateless, apart from address configuration. However, having said that, most folks will still be using mobile handsets which don't support BNEP for the foreseeable future. Unfortunately this means rfcomm_sppd still needs to play nice with userland ppp. Of course for the typical use case, as I undestand it, rfcomm_pppd is going to be invoking rfcomm_sppd as a wrapper, so pipes are just fine (and in fact probably already being used). Maksim seems to be talking about the use case where folk are actually doing straight serial over RFCOMM and need to tie it down to a known tty, though. Surely there must be a way to tie rfcomm_sppd down to a specific pts number, or failing that, teach it to report the pts which it got allocated? cheers, BMS