HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed

[Julian Elischer]

Maksim Yevmenkin wrote:
> On Tue, Feb 17, 2009 at 11:21 AM, Ed Schouten <ed at 80386.nl> wrote:
>> * Maksim Yevmenkin <maksim.yevmenkin at 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 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"