HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed

[Maksim Yevmenkin]

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 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