[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: console plans

From: Marcus Brinkmann
Subject: Re: console plans
Date: Tue, 25 Jun 2002 02:34:03 +0200
User-agent: Mutt/1.4i

On Wed, Feb 13, 2002 at 04:36:31AM -0500, Roland McGrath wrote:
> > the dimensions need to be reported back to the user (SIGWINCH anyone?  I
> > think we are missing support for that in the Hurd, and in term in
> > particular).
> It's all there.  term generates SIGWINCH when TIOCSWINSZ is done on the
> terminal (or on the master half of a pty; that's what xterm does).  In
> Unix/Linux console drivers, there is an implicit simulated TIOCSWINSZ done
> by the kernel when the console is adjusted.  I think the appropriate thing
> in your model is to have /hurd/console implement this part of the tioctl
> interface, including sending SIGWINCH to the controlling pgrp--which should
> be just the attached term translator.  You can add this to the hurdio
> bottom half now and test it with term stacked on term: when it gets
> SIGWINCH, do TIOCGWINSZ on the underlying term and propagate the change up
Should this be TIOCSWINSZ?

> as S_tioctl_tiocswinsz does.  The whole pgrp signalling thing is sort of
> icky and will get dicey if we ever have one term process handling multiple
> terminals.  But it's there.

I am unsure about this.  Let's start with initialization.  Currently, the
console can report back the size of the screen with TIOCGWINSZ, while
TIOCSWINSZ is ignored (changing the size of the screen is simply not
supported right now).  However, nothing ever calls TIOCGWINSZ on the console
node.  It seems to me that it is terms responsibility to call TIOCGWINSZ on
the underlying node at initialization.  Currently, it just sets the
dimensions to all zero.  I don't see how the console server can send a
simulated TIOCSWINSZ unless as a response to a tiocspgrp, which means that
term should do that in the hurdio backend.  It needs to do that anyway, to
be able to send SIGWINCH to it when the size is changed in response to some
other event (let's say an fsysopts call).  So maybe this is how it should
be initialized?

It is important that term is initialized correctly, because otherwise LINES
and COLUMNS will default to 24 and 80, which is one off in the number of
lines for the default settings.

> > What I am in particular not sure is how we would get a getty on such
> > virtual consoles (surely we would use some /etc/ttys entry, maybe some
> > support needs to be added there).
> Nothing special happens on GNU/Linux or BSD.  It's just standard to list
> several virtual terminals in ttys or inittab (/dev/tty[1-8] on your
> GNU/Linux system).  But it would make sense to have some kind of feature
> where pressing some key would create a new virtual terminal and run some
> command on it, and that could be configured to give you gettys on demand.

Ok.  What about the client?  Will that be started by console-run, or later?

`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

reply via email to

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