Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed

On Tue, Feb 17, 2009 at 10:21 AM, Ed Schouten <ed_at_80386.nl> wrote:
> Hi Maksim,
>
> * Maksim Yevmenkin <maksim.yevmenkin_at_gmail.com> wrote:
>> On Tue, Feb 17, 2009 at 9:55 AM, Ed Schouten <ed_at_80386.nl> wrote:
>> > * Maksim Yevmenkin <maksim.yevmenkin_at_gmail.com> wrote:
>> >> so, for now, i think we should keep rfcomm_sppd(1) as it is. if this
>> >> is not an option (with new tty subsystem) then we should convert it to
>> >> use nmdm(4) or something similar.
>> >
>> > Well, the problem with the current approach is that if you remove
>> > "device pty" from your kernel config, it won't work. With MPSAFE TTY we
>> > switched to Unix98-style pseudo-terminals, so the preferred mechanism is
>> > to call posix_openpt() (or open /dev/ptmx) and use ptsname() to
>> > determine which character device to use.
>>
>> is there a way allocate tty with a given name under "new world order"?
>
> No, there isn't. I have been thinking about this. Allowing
> pseudo-terminals to be allocated with a certain name would allow us to
> do things like implementing device drivers as a daemon in userspace.

ok

>> > I won't change anything now, but will keep my patch at the before
>> > mentioned URL.
>>
>> like i said, the only problem i have here is that any rfcomm_sppd
>> callers will have to do extra work to figure which tty was allocated.
>> that is the biggest difference from user's point of view.
>
> Well, we already have existing tools that use such an approach as well,
> like mdmconfig. They print a name of the md device to stdout. I'm not
> saying I'm 100% happy with this approach, but it's more correct than
> just reserving a certain pseudo-terminal device name.

do you mean mdconfig(8) and its ability to print auto-allocated
/dev/md device unit? if so, it can also allocate specific /dev/md
unit, so it really has both options. your patch simply eliminates one
of the option and forces users to always use auto-allocation. i'm not
saying its bad, i'm just saying its different from what it used to be.
that is all.

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.

thanks,
max