Re: ut_id questions

[Zack Weinberg <zack@rabi.columbia.edu>]

On Tue, 27 Apr 1999 23:59:17 -0400, Daniel Jacobowitz wrote:
>On Tue, Apr 27, 1999 at 11:36:05PM -0400, Zack Weinberg wrote:
>> The /dev/pts interface comes from SVR4 by way of Solaris. It
>> consistently uses everything after /dev/ - pts/0, ttyp0, tty1, ttyS0.
>> I think this is the Right Thing.  Are the consistency problems inside
>> libc, or is it just user apps?
>> 
>> >Also, utmp(5) claims that the ut_id should be 'p' followed by the
>> >number - which seems like a really bad idea, since ttyp0 and pts/0
>> >would then have the same ut_id.
>> 
>> The Solaris docs describe ut_id as containing the "inittab id, if any"
>> which strikes me as useless.  Did you mean ut_line?
>
>
>For the first part, you are right, but you're referring to ut_line. 
>ut_id seems to be a timesaver cache value - a four-character, less
>human-readable identifier.  It's used to do utent compares quickly. 
>And it is completely defeated if applications can't agree on what to
>put there.
>
>Libc never sets ut_id at all that I can see, so there are no internal
>problems, but I figured libc should probably at least document the
>standard.  The ut_id entries in the info pages have that same useless
>comment.
[...]
>So it can be searched by, and glibc uses it to compare whether two
>entries are for the same terminal.  Its value, however, is unspecified,
>and applications have widely varied opinions of what it should be.
>
>Even if there is no "right answer" currently, I believe that there
>should somewhere be a standard, especially if it is ever to function
>for Unix98 PTYs.

Actually, getut[x]id() ignores ut_id if its first character is ASCII
NUL; in that case it compares by ut_line.  pututline() blindly writes
whatever it is given, so if apps put inconsistent junk in ut_id, we
lose.

I would be inclined to put an encoded representation of the device
number in ut_id.  The problem with that is if the kernel ever
goes to 32-bit major and minor numbers as anticipated, we don't have
enough room, unless we use an encoding that's aware of the meaning
of those numbers, which is wrong IMO.

zw