Subject: Re: /dev/ptmx
To: None <firstname.lastname@example.org>
From: Christos Zoulas <email@example.com>
Date: 05/24/2004 23:30:11
In article <firstname.lastname@example.org>,
Sean Davis <email@example.com> wrote:
>On Mon, 24 May 2004 18:34:27 -0400, Christos Zoulas <firstname.lastname@example.org> wrote:
>> On May 24, 6:19pm, email@example.com (Sean Davis) wrote:
>> -- Subject: Re: /dev/ptmx
>> | Would we, then, also get /dev/pts/<number> for name <-> pty mapping?
>> | That's one of the few things I like better about Linux than BSD...
>> | There are only so many /dev/ttyXY's you can use, and it looks quite
>> | obnoxious in 'w' or 'who' compared to Linux, where you just see
>> | 'pts/whatever'. Of course, I don't claim to know what the official
>> | stance on any of this is, so I'm just tossing out an opinion.
>> I'd love that but it will break too much software...
>I don't see how... certainly software would need changing, but we're
>talking about making our pty implementation meet POSIX 2001 standards
>anyway, right? If the change to the pty allocation/deallocation stuff
>is as different as is implied by this thread, the software is going to
>be broken one way or another, isn't it?
>As it is.. all I can think of that this would break would be things
>that mess with utmp/utmpx, and I would imagine utmp/utmpx could be
>fixed easily enough. I haven't looked that deeply into the pty code
>personally, but it seems like we might as well go all the way if we're
>going to do the 'Unix98 ptys' thing in the first place. I don't know
>if POSIX 2001 specifies a pts/etc filesystem, I don't think it does
>(but again, I'm getting this from implication earlier in the thread, I
>haven't read the standard myself)... but it looks so much nicer to
>dive pts/7 ip68-100-173-33. Fri 1pm 0.00s 0.03s 0.02s screen
>dive pts/23 ip68-100-173-33. 3:51pm 13.00s 0.01s 0.01s -tcsh
>dive pts/27 ip68-100-173-33. 3:51pm 9.00s 0.01s 0.01s -tcsh
>dive pts/28 ip68-100-173-33. 3:51pm 6.00s 0.01s 0.01s -tcsh
>dive pts/29 ip68-100-173-33. 3:51pm 2.00s 0.03s 0.03s -tcsh
>in 'w' output than:
>dive pc - 6:50PM 0 -tcsh
>dive pd - 6:50PM 0 -tcsh
>dive pe - 6:50PM 0 -tcsh
>dive pf - 6:50PM 0 -tcsh
>dive pg - 6:50PM 0 -tcsh
>dive ph - 6:50PM 0 -tcsh
>dive pi - 6:50PM 0 -tcsh
>(although the rest of the linux w output, the cputime stuff, can go,
>as far as i'm concerned)
You'll still need hacks for the hardwired ptys.
>I'm not saying a cosmetic change is worth breaking tons of software, I
>just don't see how it's going to break "too much" stuff. If it's not
>too much trouble, can you explain what it'll break and why? I'd be
>happy to devote some time to looking at how badly it'd break those
>things and seeing about fixing them. Our utmp/utmpx already breaks
>things in some instances - the major one being ssh.com's sshd2 on
>-current. Sometimes when a user logs out, it never pulls them out of
>utmp, even though it's been modified to use logoutx() in exactly the
>same manner as OpenSSH sshd.
It probably needs to call logout() too, to kill the utmp line. logoutx()
only kills the utmpx line.