linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Antonino A. Daplas" <adaplas@gmail.com>
To: Jon Smirl <jonsmirl@gmail.com>
Cc: Andrew Morton <akpm@osdl.org>, Greg KH <greg@kroah.com>,
	Linux Fbdev development list
	<linux-fbdev-devel@lists.sourceforge.net>,
	Linux Kernel Development <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/5] VT binding: Add new doc file describing the feature
Date: Sun, 11 Jun 2006 08:21:13 +0800	[thread overview]
Message-ID: <448B61F9.4060507@gmail.com> (raw)
In-Reply-To: <9e4733910606101644j79b3d8a5ud7431564f4f42c7f@mail.gmail.com>

Jon Smirl wrote:
> On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> > I may be looking at the problem a little differently. I see the
>> > drivers like fb, vga, etc as registering with the console and saying
>> > they are capable of providing console services. I then see the console
>> > system as opening one of the registered devices. A driver is free to
>> > register/unregister whenever it wants to as long as it isn't open by
>> > the console system. Console can only open one driver at a time.
>>
>> No, this isn't true.  You can have multiple console drivers active,
>> that's why you have a first and last parameter in take_over_console().
>> Thus at boot time, the system driver will take consoles 0 - 63.
>> Later on when a driver loads, it can take over consoles 0 - 7, leaving
>> consoles 8 - 63 to the system driver.
>>
>> To put it another way, console drivers can register for consoles 0 - 63,
>> but the user may choose to use it only for consoles 0 - 7.
>>
>> This is another reason for the system driver, it makes the unbinding
>> behavior predictable.  Without a system driver, guessing which driver
>> replaces the just unbound one may become just a tad bit confusing for
>> the typical user.
> 
> I find the whole console/tty layer to be quite confusing to talk
> about. I am mixing up console as in where printk goes and console the
> video card login device. The part about making everything equal was
> directed towards the printk output device.
> 

Sorry about that, I probably should use VT or VC for the main topic
of this thread, and plain 'console' for where the printk output goes.

This illustration might help, though I'm not sure if it's entirely
correct. The main topic of this thread deals with the VT branch only.

Console
   :
   :-----:-----------:--- etc
   :     :           :
   VT    Serial      Net
   :
   :--------:-------:-----etc
   :        :       : 
   vgacon   fbcon   newport_con
   :        :       :
   :        :       :
   hardware fbdev   hardware
            :
            :
            hardware


> I see now that you can have tty0-7 assigned to a different console
> driver than tty8-63.
> Why do I want to do this?

Multi-head.  I can have vgacon on the primary card for tty0-7,
fbcon on the secondary card for tty8-16.

> Why do we need 64 predefined tty devices?

I don't know, but no one's stopping you to redefine MAX_NR_CONSOLES to
a lower or higher number.

> 
> Googling around the only example I could find was someone with a VGA
> card and a Hercules card. They setup 8 consoles on each card.
> 
>> > Over time it would nice if these all merged to a single
>> > interchangeable interface. I would really like to be able to
>> > dynamically switch to serial/net while debugging a video driver. Is
>> > there some fundamental reason why these can't be merged?
>>
>> It's already possible to redirect the system messages to two different
>> console classes, ie with the boot parameter:
>>
>> console=tty0,ttyS0 /* direct output to VT and serial console */
>>
>> And you can already choose the console you want by adjusting
>> /etc/inittab.
> 
> How can I change where printk are going at run-time? I didn't know you
> could do that.

I really don't know.  Maybe we have some kind of entry in /proc somewhere?

Tony

  reply	other threads:[~2006-06-11  0:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-09  8:40 [PATCH 5/5] VT binding: Add new doc file describing the feature Antonino A. Daplas
2006-06-10  5:53 ` Jon Smirl
2006-06-10 13:27   ` Antonino A. Daplas
2006-06-10 16:16     ` Jon Smirl
2006-06-10 17:01       ` Jon Smirl
2006-06-10 17:22       ` Jon Smirl
2006-06-10 21:26       ` Antonino A. Daplas
2006-06-10 23:44         ` Jon Smirl
2006-06-11  0:21           ` Antonino A. Daplas [this message]
2006-06-11  0:49             ` Jon Smirl
2006-06-11  1:05               ` Jon Smirl
2006-06-11  1:44                 ` Antonino A. Daplas
2006-06-11  2:26                   ` Jon Smirl
2006-06-11  3:05                     ` Antonino A. Daplas
2006-06-12  8:31                   ` Geert Uytterhoeven
2006-06-11  1:16               ` Antonino A. Daplas
2006-06-11  2:05                 ` Jon Smirl
2006-06-11  3:03                   ` Antonino A. Daplas
2006-06-11  3:27                     ` Jon Smirl
2006-06-11  4:36                       ` Antonino A. Daplas
2006-06-11  4:46                       ` Antonino A. Daplas
2006-06-11 20:59                         ` Jon Smirl
2006-06-11 22:04                           ` Antonino A. Daplas
2006-06-11  3:09             ` Randy.Dunlap

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=448B61F9.4060507@gmail.com \
    --to=adaplas@gmail.com \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=jonsmirl@gmail.com \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).