On Mon, 28 Mar 2016, Timo Buhrmester wrote: > I've been running the below patch for about a year, which makes > rfcomm_sppd (bluetooth-related) optionally use openpty(3) when the > argument to -t is "auto". > > I'm neither sure this is the right way to do it, nor that support for > manually specifying a tty is still needed at all. > > Anyway I figured I toss it here for people to look at. If it is > considered okay, I'd also update the man page to reflect the change. > > It might be somewhat hackish. > > Any comments?
Well, I think FreeBSD switched to using openpty() altogether in the past some time but I didn't change ours because although I think that a dynamic system may be better I'm not sure if it was helpful -- the problem I saw with this is that rfcomm_sppd is used to set up an IO channel, and the script or whatever that is using it then doesn't know the name of the channel (it has to parse the output - and there are sometimes problems opening Bluetooth connections) but then I'm not sure if the current method where you set up a channel with the pre-configure name directly is useful either. What is your use case for this? The one way I did use this program intensively in the past was with pppd which runs the rfcomm_sppd program directly and uses stdio to communicate with the remote. I possibly have another use case for the future, but I haven't set it up yet - on my boat I have a NMEA->RS232C output for the instrument data. Then, I have a RS232C->Bluetooth serial dongle which provides a RFCOMM channel. I was hoping to connect this to OpenCPN one day but I don't know what would be the best system for that. I can set up OpenCPN I think to communicate with a named tty but I don't think it can run a program or use Bluetooth directly. personally in a style way, I don't like to overload functions or options in this way, perhaps better to use a separate function and -T flag ? iain
