From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 17:50:50 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56245106576D for ; Tue, 17 Feb 2009 17:50:50 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f224.google.com (mail-gx0-f224.google.com [209.85.217.224]) by mx1.freebsd.org (Postfix) with ESMTP id DEF468FC23 for ; Tue, 17 Feb 2009 17:50:49 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk24 with SMTP id 24so5544894gxk.19 for ; Tue, 17 Feb 2009 09:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c4vfJFy+zGkLqP2KJnaUpIvzBaqaDo4y7jaEbQDAikc=; b=H33Ioq4Twuaf9qV+nYqtXIh1LOhByaLMdI12K0vCXLDgd8BmshYKkHqYCzu/zzn46d 5uzS6vPmIX1XLziS6kUs8zqZ6u/aA0diUHsVlM+dzZ2Z7yW9SwOyVgw+DgYbreXBtmhJ n3Tcvdq6Wu6P+4LR+W1oG9FHgGR9gI1NEmhtU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rqtZKNW0JURxfPje39lPU+25x+m+iGI2S8tlrbj/EYgjYXu+X8aB34JMv7h+ADfjR2 eW5VRoVcVU/b1MKjfuaguHKf4iP1FgfmhX1tTBg2ytuEa7gnSUZeHzq8VVdMsGMxUdXt SjBOvHEqm8a8SiDE9rg347DVVdNxNRHIpUlyk= MIME-Version: 1.0 Received: by 10.231.12.12 with SMTP id v12mr495779ibv.4.1234893049159; Tue, 17 Feb 2009 09:50:49 -0800 (PST) In-Reply-To: <20090217115651.GE79178@hoeg.nl> References: <20080526110543.J26343@fledge.watson.org> <4999F7F9.4030204@elischer.org> <499A024A.60209@protected-networks.net> <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> <20090217115651.GE79178@hoeg.nl> Date: Tue, 17 Feb 2009 09:50:48 -0800 Message-ID: From: Maksim Yevmenkin To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Butler , current@freebsd.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 17:50:52 -0000 On Tue, Feb 17, 2009 at 3:56 AM, Ed Schouten wrote: > Hello Michael, > > * Michael Butler 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