On Tue, Feb 17, 2009 at 3:56 AM, Ed Schouten <ed_at_80386.nl> wrote: > Hello Michael, > > * Michael Butler <imb_at_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_at_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, maxReceived on Tue Feb 17 2009 - 16:50:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:42 UTC