Subject: Re: something funny about tty's on 2.6.4-rc1-mm1
From: Albert Cahalan <albert@users.sf.net>
To: linux-kernel mailing list <linux-kernel@vger.kernel.org>
Cc: akpm@osdl.org, hpa@zytor.com
Content-Type: text/plain
Organization: 
Message-Id: <1078287119.2255.403.camel@cube>
Mime-Version: 1.0
Date: 02 Mar 2004 23:12:00 -0500
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1385
Lines: 41

Andrew Morton writes:

> The (untested) first-fit patch I proposed uses
> a radix tree, so it should in fact be faster
> than the old code.
>
> Are you now thinking that we might need to
> change the pty allocator?

I just re-read Edgar Toernig's comment... oh yeah.
Contemplate BOTH parts of the utmp quote:

: char ut_id[4];     /* init id or abbrev. ttyname */
: ...
: xterm(1) and other terminal emulators directly create
: a USER_PROCESS record and generate the ut_id by using
: the last two letters of /dev/ttyp%c or by using p%d
: for /dev/pts/%d. If they find a DEAD_PROCESS for this
: id, they recycle it, otherwise they create a new entry.

The utmp or utmpx record is about 1/2 a kilobyte.
The records get added to a file. They only get
recycled when the tty is recycled.

So that's a 20 bit minor, 9 bits of utmpx record size...
and thus a file that grows to half a gigabyte.

The reasons are adding up quickly:

1. half-gigabyte utmp,wtmp,wtmpx,utmpx file
2. breaks ut_id, even if 1000 ptys not used
3. a pain to type ("ps -t 1018493")
4. screws up column widths (ps, w, top...)
5. breaks old dev_t, even if 256 ttys not used


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/