On Tue, Feb 17, 2009 at 3:56 AM, Ed Schouten <ed@80386.nl> wrote:
quoted text
> Hello Michael,
>
> * Michael Butler <imb@protected-networks.net> wrote:
>> I have NETGRAPH_BLUETOOTH et al defined in my kernel which automagically
>> creates /dev/ubt0. With the appropriate entries in
>> /etc/bluetooth/[hosts|hcsecd.conf], I simply do ..
>>
>> imb@toshi:/home/imb> less bin/gps-connect.sh
>> #!/bin/sh
>> /usr/bin/rfcomm_sppd -b -a QstarzGPS -t /dev/ttyp9
>>
>>  .. to bring it out to a device where roadnav or gspdrive can read it.
>>
>> Should I be doing something else in this script now?
>
> Well, this is not related to IFF_NEEDSGIANT and everything's fine, but
> there is something else I don't like about this approach in general (the
> way rfcomm_sppd works), namely that you `hardcode' a PTY name on the
> command line. There is never a guarantee ttyp9 is available for use,
> because another user can use it to log in with SSH, for example.
>
> Can you try this patch?
>
>        http://80386.nl/pub/rfcomm_sppd.diff
>
> This changes the -t switch to take no argument and let the pseudo-
> terminal be allocated with posix_openpt(). Unfortunately I don't know
> how practical this is for rfcomm_sppd. So let me get this straight: when
> you use rfcomm_sppd -t, the application itself will not give any output
> and will close immediately (because it is run in the background).  Maybe
> we could change it to just printf() the pseudo-terminal name, so you can
> do something like this:
>
>        TTYNAME="`rfcomm_sppd -b -a QstarzGPS -t`"
>        # Use $TTYNAME here
>
> Any opinions on the subject? (Other people as well?)

well, actually, the whole reason for providing tty name is to make
sure rfcomm_sppd uses the specified tty. that is, if you want to
_provide_ serial port service you need a "virtual serial port
emulating entity" (aka tty :) . and, yes, you are correct, there is no
guarantee that user specified tty will be available, but usually
specifying high enough tty number works. perhaps the whole thing
should be switched to use nmdm(4) or something like that.

also, rfcomm_sppd(1) can use stdin/stdout instead of tty. this makes
it possible to use rfcomm_sppd(1) in, for example, ppp(8) like so

set device "!/usr/bin/rfcomm_sppd -a my_phone -c dun"
...

this way rfcomm_sppd(1) will be started/killed by ppp(8) when it needs
to open/close ppp connection using bluetooth enabled phone as wireless
modem.

so, for now, i think we should keep rfcomm_sppd(1) as it is. if this
is not an option (with new tty subsystem) then we should convert it to
use nmdm(4) or something similar.

thanks,
max
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"