Date: Tue, 17 Feb 2009 11:51:45 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> To: Ed Schouten <ed@80386.nl> Cc: Michael Butler <imb@protected-networks.net>, current@freebsd.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed Message-ID: <bb4a86c70902171151g7cc1c23xd5ee3950c2158b80@mail.gmail.com> 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> <bb4a86c70902170950u7ec9523fl4e39360b71b66d59@mail.gmail.com> <20090217175512.GG79178@hoeg.nl> <bb4a86c70902171003v1a85b077p923e4e0e3fa1436d@mail.gmail.com> <20090217182128.GH79178@hoeg.nl> <bb4a86c70902171107t1ff97a95h1bf67938dc675e8c@mail.gmail.com> <20090217192152.GI79178@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 17, 2009 at 11:21 AM, Ed Schouten <ed@80386.nl> wrote: > * Maksim Yevmenkin <maksim.yevmenkin@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70902171151g7cc1c23xd5ee3950c2158b80>