Subject: Re: /dev/ptmx
To: None <>
From: Christos Zoulas <>
List: tech-kern
Date: 05/24/2004 23:30:11
In article <>,
Sean Davis <> wrote:
>On Mon, 24 May 2004 18:34:27 -0400, Christos Zoulas <> wrote:
>> On May 24,  6:19pm, (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...
>> christos
>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'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.