Re: looking for testers of new console

[David Walter]

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

> On Fri, Sep 20, 2002 at 09:20:25AM -0400, David Walter wrote:
>> But, I had the following error when  trying to scroll back after using
>> this for a while.
>> 
>> console: ../../hurd/console-client/ncursesw.c:462: ncursesw_scroll:
>> Assertion 'delta >= 0' failed.
>> Aborted.
>
> This is only supposed to happen if you scroll back into the scrollback
> buffer.  This is not possible with the ncursesw client because you can not
> scroll back, there is no key assigned to it.

> The only way this can happen is to start the ncursesw and pc_kbd driver in
> one console program and scroll back on the pc_kbd driver.  Is this what you
> did?

Right, this was what  I did, and it  does allow the other functions to
work (as in A+F# switch to console). 
>>>> from a separate mail >>
me>> I had tried adding it to /libexec/rc at the end, but it complains
me>> about the terminal type.

marcus> Note that you should redirect /dev/console then.  Try Roland's
marcus> new fsysopts for term to do that.

I don't understand this. what is the  device type for the redirection?
Where should it be redirected to?

Does runsystem change this prior to single user mode to the existing

     settrans -fg /dev/console /hurd/term /dev/console device console 

And then redirect the console to another vt (tty12) for example?

    settrans /dev/vt12 /hurd/term /dev/vt12 device /dev/vcs/0/console

Then if the console client fails reset the console to the initial
device?

Is there a danger  of not having  access to the underlying console  by
creating a circular dependency?
    
me>> I tried   adding export TERM=mach-color  but it  failed still and then
me>> started the default console.

marcus> Do you talk about the ncursesw client?  I am not sure that
marcus> would work.

I was trying this  in response to what I  thought was a statement that
the console ncursesw client wouldn't work in the runsystem script.

>> sh-2-05a# kbd queue full
>> kbd queue full
>> 
>> Even pressing the control key gives this message.
>
> Strange.  I don't know where this is coming from, maybe from Mach?

Sorry no clue,  if I get this again,   with some of the workarounds  I
have found, I might be able to try to find the responsible process.

>> Of course there  is the issue  of some 'lone gun'  walking up  to your
>> machine  with the console  running  and c+a+bksp  gaining root  at the
>> single   user prompt,  but  I   imagine an   option for  --no-kill  or
>> --reboot-on-kill when we get around to security issues?
>
> It's not about security, because you are trying to do the wrong thing (you
> remove the wait command).  The console client will be run like xdm or any
> other daemon, and the rc script will continue running.  That's why you have
> to redirect /dev/console before starting the console client, and change the
> /etc/ttys to something to work with that.

I had tried this both ways.  One with wait, one without.

If the console  is killed with the wait  command, it fails to  restart
anything, apparently hanging,  if you are lucky,  you can  attach from
another machine and remotely restart the local console with the -d vga
-d pc_kbd option, but perhaps  if I understand the console redirection
that will explain this as well.

> I think there should be a wrapper daemon that starts the console client in a
> loop, so if you exit it, it will be restarted.

What does it do if the daemon dies, won't that give the same behaviour
I am seeing now, not that this isn't the desirable behaviour?


-- 
/^\
\ /     ASCII RIBBON CAMPAIGN
 X        AGAINST HTML MAIL
/ \