Re: term & user space console

[Marcus Brinkmann]

On Sun, Jan 27, 2002 at 07:39:08PM -0800, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> 
> > On Tue, Dec 18, 2001 at 01:36:47PM -0800, Thomas Bushnell, BSG wrote:
> > > >   error_t (*assert_dtr) (void);
> > > 
> > > Turn on DTR.
> > > 
> > > >   void (*desert_dtr) (void);
> > > 
> > > Turn off DTR.
> > 
> > In the hurdio backend, what would be the appropriate behaviour respective to
> > blocking?  I am a bit confused about that because I try to take devio as an
> > example, but D_NOWAIT doesn't work as we would like it to work in Mach.
> 
> Um, for these specific functions?  Neither of these opens the
> terminal, and neither should ever block.

Ah, okay, I was utterly failing at communicating my question.  My bad.

It was my impression that the devio handler tried to detect a blocking write
and would interpret it as carrier off.  So my question is along that line,
but for the hurdio handler.  What I am asking about is the semantics between
the hurdio node and the hurdio bottom handler.

> > Should the underlying node be opened with O_NONBLOCK?   
> 
> This has neither a "no" answer nor a "yes" answer.  It depends on what
> operations the underlying port supports and where and how you choose
> to do the open.  Opening things is the bottom half's responsibility,
> and the top half just doesn't have that concept.

Yes, I want to know specifically about the hurdio bottom handler.

> > Should read/write operations be performed in that mode as well, and
> > DTR turned on/off along with that?  
> 
> The bottom half should assert and de-assert under the strict control
> of the top half, by the two functions mentioned above, as well as the
> mdmctl interface.

That sentence of mine was particularly vague.  Second try: If we interpret
EWOULDBLOCK as carrier off reported by the underlying ioport, then we'd call
hurdio_desert_dtr, not?

> > Is asynchronous I/O still necessary if we assume proper blocking behaviour
> > by the ioport?
> 
> I'm not sure what you mean by "proper blocking behavior".

If I use the ioport in non blocking mode, and EWOULDBLOCK triggers that
carrier off/dtr off thingie, it doesn't seem to me that I need to use
asynchronous IPC as long as the underlying ioport doesn't cheat and block
anyway.  Or, the other way round: Does the devio use asynchronous IPC to
work around the problem that a Mach device could block although we ask it
not to block?

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de