On Sun, Jan 27, 2002 at 07:39:08PM -0800, Thomas Bushnell, BSG wrote: > Marcus Brinkmann <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
