[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: |
18 Dec 2001 13:24:58 -0800 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> 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.