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 20:04:31 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

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

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

Um, no.  When DTR goes off, the Mach serial device code reacts by
destroying the receive right associated with the device.  The result
will be that attempted calls to device_write_request_inband will fail
with MACH_SEND_INVALID_DEST, which the bottom half says "oh, DTR has
gone off" and it calls devio_desert_dtr.

But it would be insane to directly think "oh, I'll do hurdio this
way".  This is the way the Mach device interface works, an interface
which sucks, and the job of devio.c is just to adapt to it as best as
it can.

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

Well, when do you want to do the opens?  It's up to you, as a bottom
handler writer.  I haven't thought about all the cases: I'm describing
what term expects from the bottom half.

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

But we should not do that.  This would be to copy an insane interface
from the Mach device layer and try and replicate its insane features.

Part of the problem here is that serial devices are *devices*, with a
complex thing called "modem state".  Hurd ports do not have modem
state--though those which implement the relevant parts of tioctl *do*
have modem state.

So your job is to:

1) Make sure that if the underlying port *does* have modem state (does
   implement the relevant tioctl calls), the interposed layer is
   suitably transparent.  I think--but maybe not.
2) For Hurd ports, which don't have all the features of serial lines,
   do something that makes the normal cases work as plausibly as
   possible.

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

Do you know any existing Hurd I/O server that returns EWOULDBLOCK to
mean "carrier has dropped" (which actually means "CTS went clear")?
Since the answer is "no", then it can't be right for hurdio.c to
depend on such a non-existent semantic for Hurd ports.  The reason is
that Hurd ports don't *have* a notion of "carrier has dropped".

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 what you should detect and report as a CTS drop.  (And
the result of a CTS drop is to de-assert DTR and call
report_carrier_off.)

Are you clear on the meaning of the DTR and CTS modem bits?

Thomas




reply via email to

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