This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pty issues (when it changes)

we understand that fact, which is why we are trying to solve it by
virtualizing the pty.  So that one would open a "virtual pty" and it
would be mapped onto a real system pty.  We could then keep track of
changes to the pty state (ioctl or what not) and redo it on restart. 
Can you imagine any issues with this if we had a virtual /dev in a
chroot'd environment so that the application would always think it had
the same exact ptys (from an fs point of view), but our kernel module
would be doing the heavy lifting so that any read/writes/ioctls to that
"Virtual pty" would go to the real pty.  or are there other issues that
I dont know about (very likely, and where does one learn about this,
pulling my hair out trying to find good reference material on ptys)


shaya potter

On Wed, 2002-09-04 at 15:05, Roland McGrath wrote:
> You can't expect a restarted application to work right if you've changed
> what pty it's talking to, any more than if you'd renamed a file it had open.
> Part of the state you are checkpointing includes what the application thought
> was going on with all its descriptors and what they referred to.  If you change
> what pty the application's descriptor refers to, it may think it knows what
> the file name of the pty is and now be wrong.  You just can't win that way.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]