From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4294 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: request: increase TTY_NAME_MAX in limits.h Date: Thu, 28 Nov 2013 10:05:39 -0600 Message-ID: <1385654739.1974.291@driftwood> References: <20131109173842.GI24286@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1385740716 6854 80.91.229.3 (29 Nov 2013 15:58:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Nov 2013 15:58:36 +0000 (UTC) Cc: musl@lists.openwall.com To: musl@lists.openwall.com Original-X-From: musl-return-4298-gllmg-musl=m.gmane.org@lists.openwall.com Fri Nov 29 16:58:40 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VmQSk-00037N-PQ for gllmg-musl@plane.gmane.org; Fri, 29 Nov 2013 16:58:38 +0100 Original-Received: (qmail 6137 invoked by uid 550); 29 Nov 2013 15:58:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 6129 invoked from network); 29 Nov 2013 15:58:37 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:subject:to:cc:in-reply-to:message-id :mime-version:content-type:content-disposition :content-transfer-encoding; bh=BwFReg0g8LVku2YApQnIgM/RsIm4sXIwO/Csh8v60aE=; b=clDshyiqLWrl0xjnSpC29aF84aUuBmYuPp7CcJj50syv0ST92AbplFoG2qeKWDd/cI LP/dMh4CXDgqybe1tLIxRALwzSaDkAIt4tep13zBhdR9D+4I/oviSXELXeoZLkNsHvHa K2apeYi0UMoIOP5UInxdjqAoLSifkD7475VoAix2PMr0jRLFHG46d6ZcPuhfNbCloGSG J79W3fOukPu31CX1XuQi8YDq4IayKZaFmeKcb3oz3juDTfMcXccWxzgQU3lQKqhvwfsK fI5W4X7mf0xnxmwBphZZeSTnPZaeF86cTieSnpqEemr5CnlIzl513XuwyVVLawvz+J4C mt/Q== X-Gm-Message-State: ALoCoQkOymKC6+bF7yNdEp1aidyONesv9djZ7WIVBjJbIVZng1E6SFPefCqxPlyYUCBQSAhOmXPR X-Received: by 10.60.117.225 with SMTP id kh1mr43170899oeb.15.1385740705255; Fri, 29 Nov 2013 07:58:25 -0800 (PST) In-Reply-To: <20131109173842.GI24286@brightrain.aerifal.cx> (from dalias@aerifal.cx on Sat Nov 9 11:38:42 2013) X-Mailer: Balsa 2.4.11 Content-Disposition: inline Xref: news.gmane.org gmane.linux.lib.musl.general:4294 Archived-At: On 11/09/2013 11:38:42 AM, Rich Felker wrote: > On Sat, Nov 09, 2013 at 05:20:35PM +0000, Laurent Bercot wrote: > > > > >If we change it I think we might as well go with the glibc value =20 > of 32 > > >rather than just increasing it by 4. > > > > That would be great, thanks :) > > > > I'm honestly surprised that those buffers are so small, even in =20 > glibc. > > Sure, it takes up static space, and in practice a small value works =20 > for > > most people since it will usually be /dev/something, but since =20 > ttyname() > > is not supposed to ever fail with ERANGE or any kind of overflow, I =20 > was > > expecting the buffer to be PATH_MAX bytes. Or even dynamically =20 > (re)allocated - > > which would pull in malloc(), but text space + a bit of heap space =20 > is cheaper > > than static space. >=20 > I'm not sure exactly what glibc does; technically, there's no reason > the size of this internal buffer needs to match TTY_NAME_MAX. If they're doing an absolute path, I note that the way ttys work in lxc =20 containers with devtmpfs is something like: mkdir /dev/.lxc/$CONTAINER ln /dev/$DEVICE /dev/.lxc/$CONTAINER/ mount --bind /dev/.lxc/$CONTAINER $CONTAIN_DIR/dev (With a caveat that the tty devices are generally half a pty talking to =20 process on the host, and maybe /dev/console is a fifo or something.) In the container side, they'll presumably see /dev/thingy as usual, but =20 from the host side if you query one of those ttys and it does an =20 absolute path into a fixed length buffer, depending on how long the =20 container name is...) My point is that if the idea is "uniquely identify this device", the =20 result isn't necessarily going to be "absolute path to where the node =20 currently actually lives". Rob=