bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: term & user space console


From: Thomas Bushnell, BSG
Subject: Re: term & user space console
Date: 27 Jan 2002 19:39:08 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

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.

devio is trying to make things work for the *bad* Mach device
interface.  Don't pretend that it is an example.  It's *not*.

Instead, work from the stated semantics; and where they are unclear,
please ask. :)

> 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.

> 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.

> 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".




reply via email to

[Prev in Thread] Current Thread [Next in Thread]