Marcus Brinkmann <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
