[Top][All Lists]

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

reply via email to

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