mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Phillip Susi <psusi@cfl.rr.com>
Cc: Greg KH <gregkh@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: Multiple consoles
Date: Mon, 9 Jan 2012 22:22:34 +0000	[thread overview]
Message-ID: <20120109222234.6d34a7ad@pyramind.ukuu.org.uk> (raw)
In-Reply-To: <4F0B5808.2010900@cfl.rr.com>

> It occurred to me that there ought to be an entirely separate set of 
> virtual consoles bound to the second seat, and the second X server ought 
> to run on one of those vcs.  Or of course, you could choose to log into 
> the console and not bother with X.

X can do it without consoles.

> Looking at drivers/tty/vt/vt.c, it appears that it was written assuming 
> that there is just one linux console.  It appears to use global 
> variables for keeping track of which vc is active, etc, rather than 
> creating one or more console devices, and store the vc multiplexing 
> information in those devices.  So to fix this, vt.c and keyboard.c would 
> need significantly refactored to remove the global variables and create 
> a console device to bind vcs, keyboards, and displays to, and then you 
> could create a second one if you wanted.

Yes - in theory (you'd also have to sort out some of the passing of
variables around so that the code knew which 'console group' it belonged
to.

> Does this make sense or am I missing something?

It makes sense but it's one of a set of three problems with the tty/vt
layer IMHO

- A vt/tty is linked to a framebuffer of some sort, so you can't just
  create abstract ones plumbed into arbitary objects. Really the vt
  emulator ought to be separate from the consoles. 

- You can only have one set of vts

- The locking needs a rework, particularly the handling of crashes where
  sometimes we deadlock on the oops reporting.

and the framebuffer layer has some problems with locking and mode setting,
with hotplug, and with a complete inability to handle scatter-gather
backed consoles.

Alan

      parent reply	other threads:[~2012-01-09 22:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-09 21:11 Phillip Susi
2012-01-09 21:21 ` Samuel Thibault
2012-01-09 21:32   ` Phillip Susi
2012-01-09 21:56     ` Samuel Thibault
2012-01-09 22:07 ` Geert Uytterhoeven
2012-01-09 22:22 ` Alan Cox [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120109222234.6d34a7ad@pyramind.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=psusi@cfl.rr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®