Re: std location for system console

[Marcus Brinkmann]

On Fri, Aug 30, 2002 at 09:51:18PM -0400, Roland McGrath wrote:
> > I can write code that makes the console-console (still for lack of a better
> > name) read out the current screen content and write it back to the first
> > virtual console.
> 
> Peachy.  This makes it very UI-painless to have the minimal kernel console
> in force until normal multiuser startup.

Uuh, I was a bit too eager with that.  I have no doubts to make it work in
normal configurations, but there is a catch.  I can read out the VGA buffer
and convert the VGA font indices to unicode (or 7bit ASCII) characters.
The problem is that the console/1/console file expects a special encoding,
for example UTF-8.  Now, there are two issues: How to get the right encoding
and what to do if the encoding doesn't support the characters we want to
print?  (The attributes are not a problem.)

This seems all wrong, so here are two alternative approachs:

1. Let the client _write_ to the shared memory that is the console, and let
it write the unicode characters and attributes into the cell matrix
directly.  We might want to support that anyway for fast display hacks etc. 
If writes only happen to the cell matrix and not to the metadata (except
cursor position etc), this should be reasonably safe -- as long as there are
no other writers at the same time.

2. Allow to open "console/1/console/ENCODING" and provide a port to the
console file as "console/1/console" does now, but with the specified ENCODING
for the iconv associated with the port.  This could be simplified by
invalidating incomplete multi-byte sequences when another port to the same
console is used for writing.  This would allow us to open
"console/1/console/UTF-8" and just write to that.

I like 1 because it is simple for the console client (no need to write
escape sequences for terminal emulation or convert to UTF-8), I don't like
it because allowing others to write to the shared memory directly is
potentially destabilizing and error prone.  However, if it is only done once
at startup while the console is unused, I am fine with that.  Also, this is
a generally useful feature for display hacks.

I like 2, because it makes it easy to use different encodings for different
virtual consoles without much fsysopts hackery.  I don't like it because it
adds another directory level which means more hair to implement in the
filesystem code.  Also, the fsysopts hackery needs to be implemented for the
default color and attribute stuff anyway.  I also don't like it because it
destabilizes the character conversion if mixed writes happen with incomplete
multi-byte sequences inbetween.

I think I will just do 1 because it is by far the easier solution to
implement correctly, and it is no doubt a feature that is a straightforward
extension of the existing interface.

Thanks,
Marcus



-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/