Re: term & user space console

[Thomas Bushnell, BSG]

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

> An easier question: devio.c uses the _request and _reply functions,
> eg asynchronous I/O, which would work very well in the hurdio case,
> too.  However, for hurdio, I think it would work equally well to
> have a reader and a writer thread, which do io_select in a loop, and
> act on it appropriately.  

I think this is a very good strategy.  Mach RPCs can be split into
asynchronous IPC calls, but this is not true of most RPC systems that
we might want to port to.  So it's ok to take advantage of the Mach
semantics in Mach-specific code (like devio.c).  But in generic code
(like your hurdio.c) we should avoid Machisms where possible.

The Right Thing is surely two separate threads.  I'm not sure that
select is really necessary at all however.  

The reader thread does:

  while (1)
    read data  -- blocking
    hand returned data to middle layer
    if (CREAD is turned off)
      block until CREAD is turned on

The writer thread is similar:

  while (1)
    if (data remains to be written)
      write data -- blocking (sometimes, not often)
    block until data needs to be written

> There must be two threads, because we must always select for
> reading, but for writing only if the output is enabled.  So if you
> resume output after it has been stopped, the thread might be stuck
> in a select for reading, which we can not interrupt.

But, why do you think a select for reading cannot be interrupted?

Still, I think two separate threads and no select is better anyway.

> > Now, under the transparency principle (1) above, if the underlying
> > port is a terminal, it should DTRT.  What do terminals do when carrier
> > drops?
> 
> That's a good question.  Some terminals seem to return EIO on subsequent
> writes.

Actually, Posix specifies it exactly.  You get a SIGHUP, and if that
didn't kill you, you get EIO on future writes.  (There are perhaps a
couple more wrinkles.)  EIO is not a reliable indicator of carrier
drop, because it can be caused by any number of things. 

But terminals generate SIGHUP only when the carrier drops.  So you
detect it by checking all incoming SIGHUP signals and looking at the
refport.  If the refport is from the terminal you are using, then a
hangup has occurred.

This is a little roundabout, but should work.  I would also not have
an objection to adding a more direct interface to tioctl.defs or some
other appropriate place.

> > Are you clear on the meaning of the DTR and CTS modem bits?
> 
> Let's say, I have downloaded a Serial Programming Guide... (and even started
> to read it) ;)

Great! :)  I'm happy to help explain things there too; I know the
basic things but I'm not a total expert.