ut_id questions

Zack Weinberg zack@rabi.columbia.edu
Tue Apr 27 21:27:00 GMT 1999


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



More information about the Libc-alpha mailing list