Re: Sockets and PTYs

Holger Veit wrote:
> I have absolutely no idea how a newer TCP version would come into play
> here other than a possible (I doubt so) name clash where TCP/IP would itself
> try to fake PTY/TTY devices. But then EMX should not know about, as it
> explicitly deals with the devices /dev/ptyp* and /dev/ttyp*.

This is the culprit. EMX fails to do so under some circumstances. Let's
consider the testcase from my first mail. We create a socket and then 
open a PTY. Since sockets and file handles are independent from each 
other, it is legal, that OS/2 assigns a file handle to the PTY with the 
same number as the previously created socket. EMX is supposed to handle 
this, but fails. Why?

sys_open() in fileio.c first checks the filename whether it is
/dev/null, /dev/tty, or a PTY. First bug: the macro IS_PTY_NAME(path)
always returns FALSE because it checks for forward slashes only.
However, the driver /dev/ptms$ from xf86sup.sys returns the device names
with backslashes! (This is not really relevant for our special case, but
I found this when I tried to fix the whole thing.)

Now sys_open() issues a DosOpen() and gets a file handle for the PTY. It
then calls reloc_handle() to see if there is already a socket with that
number. Well, there is. It is now necessary to call DosDupHandle() to
get another number. Since we want to do this for a PTY we have to issue
first XF86SUP_ENADUP. Since reloc_handle() can be called from other
places, too, we call xf86sup_maybe_enadup() to do it. This checks (among
other things)
	GET_FILE (handle)->x.xf86sup.id == XF86SUP_ID_PTY,
which evaluates to FALSE, because 'handle' is the EMX handle of the
socket, and not the PTY yet to be opened. So - XF86SUP_ENADUP is not
issued, DosDupHandle() will fail and so will sys_open() and, finally,
open().

This leaves us with the question why all this wasn't a problem with the
older TCP/IP version. Probably, because sockets and file handles were 
not as independent as they were allowed to be, so the handle returned by
DosOpen() for the PTY was different from the socket number. And problems
are difficult to solve if they don't show up ;-)

Well, this is my point of view. I'd appreciate comments. Does it sound 
reasonable? My current fix is to a add a parameter (int is_pty) to 
reloc_handle() and (int force) to xf86sup_maybe_enadup(). This seems to 
work, but still has to be tested more thoroughly. The bigger problem is 
that EMX is not maintained anymore. So what shall I do with the fix?

> I rather suspect a long existing bug in xf86sup.sys that in rare situations
> refuses to open another PTY even if it is still present and unblocked. But I
> haven't found that bug for years so far. Might be some race condition?

Well, your driver (at least in this case) is not to blame. It is doing 
just fine ;-)

Regards,
Frank.

-- 
  Frank Giessler
  Klinikum der Universitaet Jena               Tel.: +49-3641-9 32 57 80
  Biomagnetisches Zentrum                      Fax : +49-3641-9 32 57 72