Date: Wed, 18 Feb 2009 21:11:46 +0000 From: Bruce Simpson <bms@incunabulum.net> To: Ed Schouten <ed@80386.nl> Cc: Michael Butler <imb@protected-networks.net>, current@freebsd.org, Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed Message-ID: <499C7992.7000705@incunabulum.net> In-Reply-To: <20090217192152.GI79178@hoeg.nl> References: <4999F7F9.4030204@elischer.org> <499A024A.60209@protected-networks.net> <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> <20090217115651.GE79178@hoeg.nl> <bb4a86c70902170950u7ec9523fl4e39360b71b66d59@mail.gmail.com> <20090217175512.GG79178@hoeg.nl> <bb4a86c70902171003v1a85b077p923e4e0e3fa1436d@mail.gmail.com> <20090217182128.GH79178@hoeg.nl> <bb4a86c70902171107t1ff97a95h1bf67938dc675e8c@mail.gmail.com> <20090217192152.GI79178@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?499C7992.7000705>