From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 21:01:48 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 7D289106566B for ; Tue, 17 Feb 2009 21:01:48 +0000 (UTC) (envelope-from prvs=julian=29260e750@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 5E4938FC18 for ; Tue, 17 Feb 2009 21:01:48 +0000 (UTC) (envelope-from prvs=julian=29260e750@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.104]) by smtp-outbound.ironport.com with ESMTP; 17 Feb 2009 12:33:00 -0800 Message-ID: <499B1F0D.4080209@elischer.org> Date: Tue, 17 Feb 2009 12:33:17 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Maksim Yevmenkin 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ed Schouten , 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 21:01:48 -0000 Maksim Yevmenkin wrote: > 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 wrote nmdm to allow two vmware machines to talk to each other across a serial link. In those days when one ran vmware on FreeBSD it could only connect to a serial port. I later discovered it also allowed me to connect gdb to the vmware instance so I could run a vmware kernel under gdb. i.e. both vmware and gdb thought they were talking to a serial port. > >> 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 > _______________________________________________ > 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"