Marcus Brinkmann <[EMAIL PROTECTED]> writes: > The mach terminal device interface is also used for the console device, > although it of course does not implement any of the status calls. This is > why STOP (^S) and START (^Q) don't work.
See below for the strategy for the fix. > The pty interface does also not handle START and STOP. It stores > the state in flags, but it does not make use of it in any way. That's a bug. > START and STOP are just one example for stuff that concerns the bottom > handler. There is a third type, TERM_ON_HURDIO, that is not implemented > yet. It seems to me that this is what I need if I want to use term with a > colortext translator that supports keyboard input (I'd call it /dev/vcon or > so). I have started hacking together support for TERM_ON_HURDIO (I coined > it fileio before I found out about the symbol), but pretty aimlessly right > now. I'd be glad if you could share with me any ideas you had about it. Probably yes. (It's not "fileio" because it should work for any io.defs implementation, not just files.) > Read and write is clear enough (using io_read and io_write on the underlying > file node), but I have basically two problems: The bottom line interface is > not documented, so I have to guess my way through it, and second, I am not > yet sure what to do about all the state, like START and STOP. Is this the > responsibility of the bottom handler, or the underlying filesystem, and if > the latter, how do we exchange the state through the i/o interface. It's really the responsibility of the bottom handler. For START and STOP, it's important to use the underlying filesystem *if* it implements the calls, otherwise, just do it in the bottom handler. (The reason is that buffering may be going on further down.) I would suggest trying the appropriate ioctl calls; if they fail, then do it in the bottom handler. Probably the same strategy should be used for Mach devices. > I am not sure how virtual consoles are going to be implemented. It seems to > me that /dev/console is always the currently active console (at least this > it is on Linux), so this port needs to be managed by the colortext (or vcon > or however we are going to name it) translator. However, how can it point > back to the terminal translator currently in use? It seems that term needs > to advertise its own port to colortext before everything can work. Is this > correct? I have no opinion on virtual consoles. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
