From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 19:51:47 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 EA30C106572C for ; Tue, 17 Feb 2009 19:51:46 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4998FC2B for ; Tue, 17 Feb 2009 19:51:46 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so1297905yxl.13 for ; Tue, 17 Feb 2009 11:51:46 -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=pSZsE/1K4R5cdm1EMr41O15KGOAjcy4V6cTlnyu13RM=; b=xZ8rp6OBjWBloAJWugMGofphmLuyH1wQBnOzQOIkLbfjAP8oGqo33nxRlWxkH4aWvu G0jVGAXSooTL3lGb97yxTtlG6dNL6hkA8DJnPrrGDW4K4uAqakhdD98UHQItHGWB2s0S hPS62cmmQubTvit3/FeQggWh5wLcc+wh4wB3A= 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=H2+sNw9WFlXXuNlzs6kUZ/5we6CxJsNHgxe2br9A9Bkbmcqf62mkehYiZ7eHFwzk+V DP76b/9ZNd61SWOx18dTfpK6mLLcqRG5YKYrBYlG7q4mf/jIhU7l0yyaI93u6ay5aCqw S89q7njIU7zMRfUYZrQBGHGYGJhQqJHFn3GWs= MIME-Version: 1.0 Received: by 10.151.26.12 with SMTP id d12mr5219657ybj.217.1234900306016; Tue, 17 Feb 2009 11:51:46 -0800 (PST) In-Reply-To: <20090217192152.GI79178@hoeg.nl> References: <4999F7F9.4030204@elischer.org> <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> <20090217115651.GE79178@hoeg.nl> <20090217175512.GG79178@hoeg.nl> <20090217182128.GH79178@hoeg.nl> <20090217192152.GI79178@hoeg.nl> Date: Tue, 17 Feb 2009 11:51:45 -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 19:51:51 -0000 On Tue, Feb 17, 2009 at 11:21 AM, Ed Schouten wrote: > * Maksim Yevmenkin wrote: >> anyway, i guess conversion to nmdm(4) is in order then. at least this >> way users will have to change /dev/tty to /dev/nmdm which is possibly >> less pain than other alternatives. while we are at it, we also could >> implement your approach, i.e. auto-allocate and print /dev/nmdm node >> if requested. > > But nmdm(4) is not really meant to be used for stuff like that, not that why not? i think its exactly what it was meant for. > I think pts(4) should even be abused for this. The reason why pts(4) is > used, is because the application tries to mimic a serial port of some > sort on which data arrives that is normally handled by some kind of > pppd. pts(4) doesn't have a lot of overhead in this setup. not really. imagine a legacy application that wants to talk some sort of serial protocol. now imagine that you want to replace your physical serial cable with bluetooth link. all you really need is 1) run rfcomm_sppd in server mode and tell it to use /dev/nmdmA 2) run legacy application on /dev/nmdmB when wireless client connects to the rfcomm_sppd legacy application will get input from /dev/nmdmB just as it would get it from /dev/cuau or whatever. the whole purpose of those little wrappers is to provide legacy application with something that looks like serial port. otherwise it is required to change the legacy application and make it aware of bluetooth etc. for example, you _could_ change ppp(8) and teach it about bluetooth etc, but why do it? its so much simpler/cleaner to write small wrapper that gives access to bluetooth link via something ppp(8) already knows about, i.e. tty and/or stdin/stdout. > 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. its not all about speed. its about flexibility. thanks, max