Re: std location for system console

[Marcus Brinkmann]

On Fri, Aug 30, 2002 at 11:09:14PM -0400, Roland McGrath wrote:
> > So you want to run it as a daemon.  How abot this:  There is a -D option
> > that starts the console as a daemon, so that it returns early.  There is
> > also an option to save the current screen content on vc 1 (or whatever), and
> > this is done before daemonizing and returning in the parent.  I think this
> > is the only sane way to guarantee that nobody writes to the hardware 
> > console.
> > Naturally, this needs to be done before a getty on tty1 is started.
> 
> Why do you need anything special?  The getty on tty1 will start the console
> server via passive translator if need be, so the backend is always there
> when you need it.  Running the console-console client on the console can be
> started whenever, as long as it's before X or whatever else it might need
> to negotiate with for hardware access.  Whenever console-console starts it
> can fetch the hardware screen contents and stuff them into the tty1
> scrollback buffer.

Oh, you want to put it in the scrollback buffer.  I was assuming that it was
stuffed in as regular data, not as scrollback, and move the cursor so that
you have a seamless transition from hardware state to virtual console with
client state.

Putting it into the scrollback buffer can only be done by writing directly
to the shared memory.  So that would answer my other question, too.  It is
an interesting idea, except that it doesn't eliminate the problematic race.

Imagine you want to write the scrollback buffer into the shared memory
region from the console client.  You are preempted in the middle of that,
and next a perversely long message of the day is printed by the login
program that was started by getty.  The message is so long, that the
scrollback buffer you are just writing to was reused for actual screen
content.  You are then writing into the screen instead of the scrollback
buffer.

No, I don't think it is feasible to allow anybody write to the console while
you are diddling it from the console client's side.

Another generic problem is making other clients aware of the data you wrote
directly into the shared memory.  Uh, this is a bottom-less pit.  Having the
console-client write back the data the regular way seems to be the easier
thing to do after all (and in this case you also have to be the exclusive,
and first, writer).

> The only thing hard to support is having old contents, then not
> clearing the screen but moving the cursor around and partially overwriting.
> But I really don't think we should care about that. 

With the above race, both are equally hard.
 
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/