Re: request: increase TTY_NAME_MAX in limits.h

[Rob Landley <rob@landley.net>]

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  
> 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  
> glibc.
> > Sure, it takes up static space, and in practice a small value works  
> for
> > most people since it will usually be /dev/something, but since  
> ttyname()
> > is not supposed to ever fail with ERANGE or any kind of overflow, I  
> was
> > expecting the buffer to be PATH_MAX bytes. Or even dynamically  
> (re)allocated -
> > which would pull in malloc(), but text space + a bit of heap space  
> is cheaper
> > than static space.
> 
> 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  
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  
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  
from the host side if you query one of those ttys and it does an  
absolute path into a fixed length buffer, depending on how long the  
container name is...)

My point is that if the idea is "uniquely identify this device", the  
result isn't necessarily going to be "absolute path to where the node  
currently actually lives".

Rob