Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed

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